Insights / Databases
Deploy database changes without a maintenance window
A safe schema migration accounts for the old and new application versions running at the same time, not only the final table shape.
Kiran Bandarupalli · 2 Oct 2026 · 2 min read
A migration can succeed in a development database and still fail during a rolling release. For some period, old and new application instances may both be talking to the same schema. Plan for that overlap explicitly.
Expand, migrate, contract
Suppose a field is being renamed. First add the new field without removing the old one. Deploy code that writes both and can read the new field with a fallback. Backfill existing rows in bounded batches. Switch reads after verification. Only in a later release, when no supported application version depends on it, remove the old field.
Keep backfills bounded
A single update over a large table can hold locks, generate a burst of replication traffic, and compete with user queries. Process by stable key ranges with a limit, record progress, and make each batch restartable. Inspect lock behavior and replication lag in a staging environment that resembles production.
Protect correctness during the overlap
Define which version owns a value when both fields are present. Dual writes can diverge if one path fails, so instrument mismatches and make repair possible. Constraints that cannot be added online should be introduced using a staged validation plan supported by the database engine.
Rollback is not always reverse
Rolling back application code may be safe while retaining an additive column. Rolling back after dropping data is not. Separate reversible deployment steps from irreversible cleanup, and take a verified backup before a destructive transition.
- Test migration duration and locking with representative data.
- Set thresholds for stopping when replication lag or errors rise.
- Monitor old and new application versions during rollout.
- Document the point after which rollback requires a forward fix.
Not every migration can be zero-downtime, and database engines differ. The method still helps: make compatibility between versions deliberate, keep data movement incremental, and do not combine a risky schema change with an unrelated feature release.