Member-only story
Zero-Downtime Database Changes: The Multi-Deploy Strategy for Django
The migration works. But can it run while your app is serving traffic?
In Article #5, I told you about the migration that locked our orders table for 47 minutes. That article covered the basics — separate data migrations from schema changes, use atomic = False, batch your updates, create indexes concurrently.
But there’s a category of database changes that those rules don’t cover. The kind where no single migration is safe, no matter how carefully you write it. The kind that requires two, three, or even four separate deployments to complete safely.
Renaming a column. Changing a field type. Removing a table that old code still references. Moving data from one table to another. These changes can’t be done in one step without breaking the application that’s still serving traffic.
The pattern that solves this is called expand-contract — and once you understand it, you’ll never be afraid of a schema change again.
Why Single-Deploy Migrations Break
