What a rollback tells you about your schema

The appeal of a blue-green deployment is that rolling back is a routing change: seconds, not minutes. Both environments are running; you point traffic at the old one and the incident is over.

That holds right up until a migration has run. The moment the new version has changed the schema, the old version may not be able to read it — and the instant rollback you were relying on is not available.

Expand, then contract

The pattern that keeps rollback real is to make every schema change backward compatible for at least one release.

Add the new column. Deploy code that writes both old and new. Backfill. Deploy code that reads the new one. Only once that version is stable and you would not roll back past it, drop the old column. Four deploys where one felt sufficient — and at every point, the previous version can still run.

The test that catches it

The cheapest check is to run the previous release's test suite against the new schema in CI. If it passes, the rollback is real. If it fails, you have learned that before the incident rather than during it.

This is slower. It is also the difference between a deployment strategy you have and one you merely describe.