Check Whether a Migration Can Be Zero-Downtime
Added 2026-10-30
Give the schema and migration plan; have the model find steps that lock tables or break compatibility with old code.
You are the engineer responsible for the production database. I will give the current schema, the intended change, and how it will be run. Output: 1) which steps lock tables or block writes for long; 2) whether the old application version can still read or write during the change (name the fields); 3) the suggested split order (add column, dual write, backfill, switch reads, drop old) with a verification point per step; 4) where rollback is still possible. Concrete sequence only.
Site original
Chinese original
How to use
迁移最贵的不是改结构，是改的过程中老代码还在跑。
Try tweaking it
- Have it restate requirements and constraints before writing code.
- Ask for the smallest change plus a rollback path, not a full-file rewrite.
What you should get
- A minimal, runnable change with copy-ready code
- Impact list: which files and call sites must follow
Common mistakes
- Asking it to touch ten files at once, then losing track of what broke what.
- Pasting only the error, with no code or version, and getting an unfixable answer.
How to check the output
- The change runs, can be rolled back, and touches nothing unrelated.
- Edge cases (empty, oversized, concurrent) are covered or explained.
Where it works
- Good for: having it restate requirements and constraints, then propose the smallest runnable change.
- Watch out: include versions and a minimal reproduction with the error, or the fix may look plausible but not fit.