#ORM integration need

5 messages · Page 1 of 1 (latest)

mighty tusk
#

Today you can ask an AI tool to generate an API, write backend logic, or even create database migrations. What used to take hours can now happen in minutes, but there is a hidden problem.
AI can generate migrations it doesn’t always understand their impact. A migration like this might look harmless:
*ALTER TABLE users DROP COLUMN email;
*
But in a production system, a single command like that can cause:
• permanent data loss
• broken application queries
• failing deployments
• costly rollbacks

There have already been cases where AI-powered development tools accidentally caused destructive database operations. Developers using tools like Claude and platforms such as Replit have reported situations where AI-generated actions ended up deleting or damaging production databases.
AI can generate SQL, but it usually does not reason about the operational risk behind those changes. As AI-assisted development becomes more common, migrations may be generated automatically inside development workflows or CI pipelines.
This alone raises an important question:
How do we know if a schema change is safe before it runs?
This is the problem I started thinking about recently, which led me to build a small tool called schema-risk.

The idea is simple: analyze database schema changes and detect dangerous migrations before they reach production.
Instead of blindly applying migrations, the tool scans them and flags risky operations such as:

dropping tables
removing important columns
structural changes that may cause data loss
It’s still very early, but the goal is to make database migrations safer in the age of AI-driven development.

GitHub: https://github.com/Keystones-Lab/dbRisk

Curious to hear from others working with databases:

Have you ever had a migration accidentally break production?

GitHub
GitHub - Keystones-Lab/Schema-risk

Contribute to Keystones-Lab/Schema-risk development by creating an account on GitHub.

trail runeBOT
#

Skipping coffee for instant knowledge! Let's brew that AI answer now.

trail runeBOT
# trail rune Skipping coffee for instant knowledge! Let's brew that AI answer now.

The concern you're raising is very real and something Prisma has been actively addressing.

Prisma's built-in safety guardrails

Starting with Prisma ORM v6.15.0, Prisma added guardrails specifically to prevent AI coding tools from running destructive commands without explicit user confirmation. [AI Safety Guardrails]

The Prisma CLI now detects when it's being invoked by popular AI agents such as Claude Code, Gemini CLI, Qwen Code, Cursor, Aider, and Replit. If one of these agents attempts a destructive action like prisma migrate reset --force, Prisma blocks execution and requires the AI to:

  • Explain what it's doing and why
  • Warn the user that data will be irreversibly destroyed
  • Confirm it's not a production database
  • Obtain explicit user consent before proceeding [Cursor Safety Docs]

Safe migration practices

Prisma also advocates a forward-only migration policy — making additive changes rather than immediately dropping columns or tables, so rolling back application code is sufficient without data loss. [Migrate Feedback]

There's also an open GitHub issue requesting safe migration warnings (similar to Rails' strong_migrations gem) that would flag risky operations like column drops, table renames, and NOT NULL additions before they're applied. [Safe Migrations Issue]

CI enforcement

Prisma recommends using CI pipelines to validate migrations before they reach production — applying them to a clean database, running integration tests, and failing the build on destructive operations. [CI Database Safety]

Your schema-risk tool aligns wel

trail runeBOT
trail runeBOT