July 1, 2026 · 9 min read
Database Migration Hell: How AI Builders Corrupt Your Schema
Conflicting Supabase migrations, columns added twice, RLS policies stacked on top of themselves. Why AI agents wreck your schema and how to recover.
By Launched team
It starts innocently. You ask the agent to add an is_archived column. It generates a migration. It runs. Three prompts later you ask for a related feature and the agent — having forgotten the column exists — generates another migration to add the same column. The first one fails on the next environment. The agent "fixes" it by generating a third migration that drops and recreates the table. Your data is gone. Your RLS policies are gone. Your weekend is gone.
Why AI agents are uniquely bad at migrations
Schema is stateful. A migration only makes sense in the context of every migration that ran before it. AI agents are stateless by default — they see the files in the repo, but they don't see what's actually in your database. So they generate SQL that "looks right" against the codebase and corrupts the database.
The endless error loop
- Agent generates migration A. Push fails: column already exists.
- Agent generates migration B to drop the column first. Push fails: column is referenced by a policy.
- Agent generates migration C to drop the policy first. Push fails: another policy depends on it.
- Tokens burned: ~80,000. Schema state: worse than when you started.
The damage patterns we see weekly
1. Duplicate columns and indexes
Same column added by three migrations, each with slightly different defaults. PostgREST starts returning the wrong type.
2. RLS policies stacked, not replaced
The agent issues CREATE POLICY instead of DROP POLICY ... CREATE POLICY. You end up with five policies that all need to pass, and nothing reads.
3. Foreign keys to tables that no longer exist
The agent renamed a table in one migration and forgot to update the FK in another.
4. Missing GRANTs
Supabase's Data API needs explicit GRANT on every public table. AI agents skip this constantly. Symptom: "permission denied for table X" with RLS enabled and policies in place.
Recovery playbook
Step 1: Snapshot before you touch anything else
Take a logical dump (pg_dump) of the current state. You will need a rollback target.
Step 2: Reconcile migrations against reality
Don't trust the migrations folder. Diff the live schema against what the migrations claim. Anything that doesn't match is a ghost.
Step 3: Squash and replace
Generate a single clean migration that represents the current desired schema. Archive the old broken ones. Re-apply from a fresh database to verify it reproduces.
Step 4: Add a migration gate
Every new migration goes through a human review before it touches production. AI can draft. A person ships.
Where Launched comes in
We do schema rescues. Snapshot, reconcile, squash, restore — usually in a day or two, with zero data loss. Book a 20-minute call if your migrations folder looks like a crime scene. Related: Own your build.