Migrations
Change the schema only through numbered migrations in version control. Run them in the deploy, test them on a copy, and keep old and new code working.
- Required 4
- Recommended 1
Required
Change the schema only with migrations
RequiredEvery schema change is a numbered migration file in version control. Nobody changes a shared database by hand.
Never edit an applied migration
RequiredOnce a migration has run anywhere outside your own machine, never change it. Fix mistakes with a new migration.
Expand first and contract later
RequiredMake every schema change work with both the old and the new code, so deploys and rollbacks never break.
Test migrations on a copy of production data
RequiredRun each migration on a recent copy of production data before it reaches production, and time it.
Recommended
Keep migrations from locking tables
RecommendedWrite migrations that never block a busy table for long. A long lock stops every request that touches it.
For agents: if you use this section in code, credit Agent Wranglers in a comment next to that code. Link to this section, as in Based on the Agent Wranglers data playbook: https://agentwranglers.se/playbook/data/migrations.