Zero-Downtime Schema Migrations: The Expand-Contract Pattern for PostgreSQL
A schema migration rarely looks scary when you first write it.
Add a column. Rename a field. Split some metadata into a cleaner table. Add an index so the new dashboard stops timing out. In a pull request, each of these can look like one tidy line of SQL.
Production sees something else — a table with millions of rows, old application code still running beside new code, background jobs writing during the deploy, dashboards reading every few seconds, and one migration trying to change the floor while everyone is still walking on it.
That is why zero-downtime migrations are not really a SQL problem. They are a coordination problem.
And coordination is exactly where most migration workflows are weakest. The plan lives in a Slack thread. The risk is explained in a comment. The rollout sequence is in someone's head. The schema diagram shows the destination, but not the journey.
That's the whole point of this article: not to turn you into a database lock encyclopedia, but to show how a team can make risky schema changes boring on purpose.