Skip to content
Codesphere
Blog

Zero-Downtime Database Migrations: A Safe Deployment Playbook

Use expand-and-contract migrations, backfills, compatibility windows, observability, and rollback planning to change production schemas safely.

Jul 17, 2026Updated Jul 17, 2026
On this page

Database schema changes are production changes. A migration that works on an empty development database can still lock a large table, break an older application version, or make rollback impossible.

#Use expand and contract

First add the new structure in a backward-compatible way. Deploy code that can read and write both forms, backfill existing data, switch reads to the new form, and remove the old structure only after all old application versions are gone.

#Separate schema and code rollout

Do not require a new application binary to understand a schema that an older binary still uses. During a rolling deployment, old and new instances may run together. Compatibility must hold across that window.

#Backfills and locks

Run large backfills in small batches with progress tracking, pauses, and retry behavior. Understand whether an index or column operation locks writes, and use the database-supported online or concurrent approach when appropriate.

#Verify and observe

  • Check migration duration and lock waits.

  • Monitor error rate and query latency.

  • Verify row counts and checksums where practical.

  • Track backfill progress and remaining old data.

  • Keep an operational owner available during rollout.

#Rollback planning

A code rollback is not always a schema rollback. Prefer forward-compatible changes and keep destructive cleanup for a later release. Document how to stop a backfill, restore a safe code path, and recover partial work.

#Frequently asked questions

#Should migrations run automatically on application startup?

It can create startup coupling and concurrent execution risk. A controlled deployment step is often easier to observe and recover.

#Can every migration be zero downtime?

Not always. Measure lock behavior, plan maintenance windows when necessary, and communicate the impact honestly.

#Conclusion

Safe database migrations are phased compatibility changes. Expand first, deploy compatible code, backfill carefully, observe the result, contract later, and keep rollback and recovery explicit.