What this prompt does
This prompt makes the AI act as a senior database engineer that converts a schema diff into safe, runnable migration scripts rather than pseudocode. You provide the [diff] to migrate, your [orm] or migration tool, and the [environment] with rough data scale. It then produces six things: a forward (up) migration, a matching down migration that fully reverses it, a batched data migration so large tables don't lock, safety checks against nulls and duplicates and re-runs, a backwards-compatibility note for live code, a seed-data test run with expected counts, and a mid-failure rollback plan.
The structure works because it forces a real down path and batching, which are exactly the parts people skip when a migration looks simple on a small dev database. [orm] decides the migration file format and command syntax, so the output matches your tool instead of generic SQL you would have to translate. [environment] is the key lever: when it says a multi-million-row table, the model leans harder on batching and lock-avoidance, because a migration that is instant on an empty dev database can lock a real table for minutes and stall live traffic. The seed-data test step gives you before and after counts so you can verify the move did what you expected before it ever touches production.
When to use it
- You are shipping a schema change against a live production database.
- You need a guaranteed down migration, not just a forward one.
- A data backfill touches a large table that could lock or time out.
- You want explicit safety checks against nulls, duplicates, and re-runs.
- You need to know whether the change is backwards-compatible with running code.
- You want a rollback plan for a migration that fails halfway through.
Example output
You get the up migration file, the matching down migration, the batched data-migration code, and the exact commands to run them, plus a backwards-compatibility note for live code, a seed-data test with expected before and after row counts, and a step-by-step rollback plan covering a failure midway through. It is formatted as runnable files and commands for your chosen tool, ready to drop into your migrations directory, not a conceptual description you still have to turn into code.
Pro tips
- Set
[environment]with real row counts; that is what triggers proper batching for large tables. - Name
[orm]exactly so the files use your tool's real migration format and commands. - Paste the complete
[diff]so the down migration can fully reverse every change. - Run the seed-data test against production-shape data, not an empty dev database.
- Always read the backwards-compatibility note before deploying alongside live code.
- Verify the down migration actually reverses the up before you trust the rollback plan.
