Schema-risk

#rust #postgres #sql #cli

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.

The problem is that database migrations are one of the most dangerous operations in software systems, and they require understanding things like:

data dependencies
foreign keys
table sizes
cascading deletes
locking behavior

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: