Ask most teams what "zero-downtime deploy" requires and the answer is all about the application tier: rolling restarts, load balancer health checks, draining connections before a pod terminates. All of that is necessary. None of it is sufficient, because the outage that actually happens usually comes from a completely different layer — the moment old code and new code are both running against a database schema that only one of them was written for.
The window nobody accounts for
A rolling deploy means, by design, that for some period — seconds, sometimes minutes — old application code and new application code are both live and both hitting the same database. If a migration renames a column, drops one, or changes a type as part of that same deploy, there's a window where either the old code is querying a column that no longer exists, or the new code is querying a column that doesn't exist yet. The server-level rollout was flawless. The outage happened anyway, at the layer nobody was watching.
The fix is sequencing, not tooling
The pattern that actually solves this is usually called expand-contract, and it trades one atomic change for a short sequence of backward-compatible ones:
- Expand: ship a migration that adds the new column/table/shape without removing the old one. Both old and new code can run against this schema simultaneously, because nothing they depend on has disappeared yet.
- Migrate: deploy the application code that writes to (and eventually reads from) the new shape, while the old shape is still present as a fallback.
- Contract: once every instance is confirmed running the new code — not before — ship a second migration that removes the old column/table now that nothing depends on it.
The unglamorous part is that this takes two deploys and some discipline about not skipping step 3, not one clever migration script. Teams that try to compress it back into a single atomic step are usually the ones that reintroduce the exact race condition this pattern exists to avoid.
Why this gets skipped
Expand-contract takes longer and touches more deploys than "just run the migration," which makes it an easy corner to cut when a schema change feels small. The failure mode from cutting that corner is also intermittent and load-dependent — it might not show up in staging with one replica and no traffic, and only appears in production during the exact window when both code versions are briefly live under real concurrency. That combination (rare, timing-dependent, doesn't reproduce locally) is exactly what makes it easy to under-invest in until it causes an actual incident.
The takeaway
If your deploy pipeline is zero-downtime at the server level but a schema change can still take the site down, the deploy pipeline was never the actual constraint — the database was. Server-side zero-downtime tooling and schema-level backward compatibility are two separate problems, and solving only the first one just moves the outage to a layer with worse observability.
