intermediate
Migrations
Version schema changes so deploys, rollbacks, data backfills, and zero-downtime constraints remain explicit.
Migrations version database schema (and sometimes data) changes. ORM tools generate SQL from model diffs, but production still needs human review, expand-contract deploys, and rollback planning.
| Phase | Goal | |-------|------| | Expand | Add nullable column or new table safe for old code | | Migrate data | Backfill in batches with monitoring | | Contract | Remove old column after all writers/readers upgraded |
On interviews: mention locks, backfills, drift detection, shadow databases, and why generated migrations are a draft—not approval.
Common pitfalls: rename becoming drop-and-create; large table DDL locking production; treating down migrations as guaranteed data restore.
The trade-off is automation speed versus operational safety during rollout.
Checklist:
- Review SQL before deploy.
- Plan zero-downtime compatibility.
- Separate schema, code, and data phases.
- Test migrations on realistic data volume.