Safe database migrations and rollback-ready deployments

Application and schema change at different speeds

During a rolling deployment, old and new application instances can run at the same time. A migration that renames or removes a column immediately may break the old version before the rollout has completed. A rollback then restores code that no longer understands the schema.

Treat compatibility as a transition state. The database must temporarily support both versions, and the application should tolerate the intermediate schema until the rollout is verified.

Use expand, migrate and contract

First expand the schema with additive, compatible changes. Deploy code that can read the old and new representation and begin writing the new one. Migrate existing data in controlled batches, then verify completeness. Only after the old code can no longer run should a later deployment remove the obsolete structure.

Large backfills should not share the release transaction. They need progress tracking, bounded batches, pause and resume controls, and observability for lock time and replication impact.

• Avoid adding a heavily validated constraint to an unverified large table in one step.
• Make migration ownership and execution order explicit in the delivery pipeline.
• Test migrations against production-like data volume and shape.

Health is more than a responding process

A liveness check answers whether the process should be restarted. A readiness check answers whether it can safely receive traffic. Combining them can create restart loops when a dependency is temporarily unavailable.

Deployment verification should include a small business-level probe in addition to infrastructure health. Confirm that the new version can perform a representative operation, emit expected telemetry and interact with the current schema.

Rollback is a tested capability

A rollback plan that assumes the database can simply reverse every migration is incomplete. Data written by the new version may not fit the old model, and external side effects cannot be undone by redeploying a container.

Define what can be rolled back, what must be rolled forward and who makes that decision. Progressive rollout limits exposure while evidence accumulates. Feature flags can separate code deployment from behaviour activation, but they also need ownership and removal dates.