Blue-Green Database Schema
The constraint that makes fast rollback actually work — both application versions must be able to run against one schema at the same time.
Blue-green deployment and canary release are both sold on rollback speed. Both quietly depend on a property nobody checks: while traffic is split, two application versions share one database.
Which means every schema change must be backward compatible with the currently deployed version, not
just forward compatible with the new one. An in-place ALTER that renames a column, drops one,
tightens a constraint or changes a type breaks the version you are about to roll back to — so the
rollback path you paid for does not exist.
The discipline is expand-and-contract, sequenced across releases: release N adds the new column and writes to both; release N+1 reads from the new column; release N+2 stops writing the old one; release N+3 drops it. Each release is independently rollback-safe because each is compatible with its neighbour.
The test to apply before any deployment: can the previous version serve traffic against the schema as it will exist after this change? If not, the deployment is not reversible, whatever the deployment strategy is called.