Part 4 · 1 chapters · ~8 min
Database Migrations During Deploys
The compatibility rule (version N and N+1 against one schema), expand and contract across several deploys, migrations run before or after the code, online DDL per engine, backfills during deploys, and migration tooling (Flyway, Liquibase, Alembic, Rails, Prisma, Atlas).
5
Compatible across two versions
the rule
- During any rollout, two versions of code run against one schema.
- So every schema change must work with the code before it and the code after it.
- Run additive migrations before the code that needs them; run destructive ones after no code uses the old shape.
- Never combine a breaking schema change and the code that depends on it in one deploy.
| tool | ecosystem | note |
|---|---|---|
| Flyway, Liquibase | JVM (and anything) | versioned SQL or changelogs, checksums |
| Alembic, Django migrations | Python | autogenerate, then review the SQL |
| Rails migrations | Ruby | strong_migrations gem flags unsafe operations |
| Prisma Migrate, Drizzle Kit | Node | generated SQL; review for locks |
| Atlas, sqitch | any | declarative diffs, linting for destructive changes |
EXPAND AND CONTRACT
renaming a column with zero downtime, across five deploys
swipe the figure sideways, or tap expand for full screen
1/5
expand
Add the new shape without removing the old: a nullable column, a new table, a new index built concurrently. Old code ignores it.
add, never remove, in the first stepold code keeps working