Can blue-green deployment preserve database schema compatibility during a zero-downtime cutover?

Answer

Yes, a blue‑green deployment can preserve database schema compatibility during a zero‑downtime cutover, provided you use an expand‑contract migration strategy and apply the schema changes before promoting the standby environment.

Confirmed facts

• The expand‑contract pattern lets both the old and new application versions read the same database simultaneously.
• Schema migrations must be applied to the shared database before the traffic switch, not before deploying the new code.
• The load balancer must drain active connections from the blue environment during the cutover to avoid routing requests to migrated schema with old code.
• Health checks should only query schema objects that are guaranteed to exist after the expand phase and after the new code is deployed.

Likely explanation (steps for this case)

1. Deploy the new release to the green environment, but configure it to use a backward‑compatible code path that can read both the current schema and the schema after the expand phase.
2. Apply the expand phase migrations (e.g., add new columns/tables, make existing columns nullable) to the shared database. These changes are safe for the old version.
3. Run health‑check endpoints against the green environment; they should only query the newly added schema objects to confirm the green stack can operate with the migrated database.
4. Drain connections from the blue environment: deregister blue instances from the load balancer, wait for in‑flight requests to finish, or use connection‑draining timeout.
5. Switch the load balancer to route all traffic to the green environment.
6. Monitor for errors. If traffic is stable, proceed to the contract phase: run migrations that remove deprecated columns/tables, enforce NOT NULL constraints, or rename columns—now safe because all traffic uses the new code.
7. If any issue appears before contract phase, you can roll back the expand migrations (if they are idempotent) and switch traffic back to blue.

Missing diagnostic detail

Ask: Does the backward‑incompatible change involve dropping or renaming existing columns, or adding NOT NULL constraints without a default value? If the answer is yes, the expand‑contract pattern is required; if the changes are purely additive, you could apply the migrations directly and skip the contract phase.