Concept explanation
Schema migrations are where tidy local SQL meets messy production reality. This game helps you rehearse the deployment order that keeps both old and new application versions alive while data moves underneath them.
All games
Schema Migration Runbook
Choose safe zero-downtime database migration steps for expanding schemas, backfilling data, rolling out indexes, enforcing constraints, and recovering from failures.
- Concept
- Zero-downtime schema migration planning and expand-contract releases
- Difficulty
- Intermediate
- Play time
- 6-9 minutes
- Path
- Data & Performance
practice/schema-migration-runbook Migration safety score Play, get feedback, save local progress, and optionally submit a leaderboard score.
Playable game area
Use the controls below. Feedback appears immediately, and final scores are stored locally.
Leaderboard
Top 10 submitted scores. No account required.
Loading leaderboard...
Finish the game to load your latest local score.
Learning objectives
- Apply expand-contract thinking to columns, renames, indexes, and constraints.
- Plan backfills that avoid unnecessary locks and production load spikes.
- Explain why schema changes must be compatible with mixed application versions.
How to play
- Read the migration goal and production constraint.
- Choose the next safest runbook step.
- Use the feedback to learn why deploy order matters as much as SQL syntax.
Scoring
- Safe migration steps add points and streak bonuses.
- Risky steps explain what could break during a mixed-version deploy.
- Your best migration safety score is saved locally.
Backend concept notes
Production migrations are distributed systems problems in disguise: old code, new code, old data, new data, replicas, locks, and retries can overlap.
Expand-contract releases add compatible schema first, move code gradually, backfill safely, validate, and only then remove old fields or enforce stricter constraints.
Common mistakes
- Renaming or dropping a column while old app versions still use it.
- Running huge backfills or index builds in the most blocking mode during peak traffic.
- Adding constraints before all writers and old rows satisfy them.
- Treating rollback as simple even after destructive schema changes.
FAQ
Short answers for how this game fits backend interview and study practice.
Why not put every migration in one deploy?
One large deploy couples application behavior, data shape, and DDL locks. Smaller compatible steps are easier to observe, pause, and recover from.
Do all databases support the same online migration features?
No. The game teaches the pattern. Production runbooks still need database-specific checks for locks, validation, concurrent index support, and replication impact.