How to Plan and Execute a Zero-Downtime Database Migration
For any application that handles real-time business operations, database downtime is not just an inconvenience — it is a direct business cost. E-commerce platforms lose revenue during maintenance windows. SaaS applications violate SLAs. Even internal business applications create productivity losses when they go down. Zero-downtime database migration techniques have become essential knowledge for any team managing production database systems.
Understanding the Challenge
Traditional database migrations take the application offline, modify the database, validate the changes, and bring the application back online. This approach is simple and safe, but it requires downtime. Zero-downtime migrations require the application and database to be simultaneously functional in both the old and new states during the transition period — a significantly more complex engineering challenge.
The key insight is that most database changes can be broken down into a series of smaller, backwards-compatible steps that can each be applied without taking the application offline. The complete migration becomes a sequence of these safe steps rather than a single atomic operation.
The Expand-Contract Pattern
The expand-contract (or parallel change) pattern is the most widely used framework for zero-downtime schema changes. It breaks migrations into three phases:
- Expand: Add new structures alongside existing ones. For example, if you need to rename a column, add the new column alongside the old one. Update the application to write to both columns and read from the old column.
- Migrate: Backfill the new column with data from the old column for all existing rows. Deploy the application version that reads from the new column.
- Contract: Remove the old column now that no deployed application version uses it.
This three-step process takes longer than a simple rename but eliminates any downtime and provides a safe rollback path at every stage.
Handling Schema Changes Without Downtime
Different types of schema changes require different zero-downtime strategies:
- Adding a nullable column: Safe in most databases; can be applied directly without application changes
- Adding a non-nullable column: Use expand-contract: add as nullable, backfill, add NOT NULL constraint
- Renaming a column: Use expand-contract: add new column, update app to write to both, backfill, update app to read from new, remove old
- Adding an index: Use CREATE INDEX CONCURRENTLY (PostgreSQL) or online DDL features of your database platform
- Adding a foreign key: Add the constraint WITHOUT VALIDATION first, then validate in a separate step
Managing Large Data Backfills
When you need to update a large number of rows as part of a migration, running a single UPDATE statement against a table with millions of rows will lock those rows for the duration of the operation — potentially causing significant application disruption even if the schema change itself was non-blocking.
The solution is to backfill in batches. Write a script that updates a few thousand rows at a time, sleeping briefly between batches. This keeps the database responsive to application queries and prevents lock escalation while still completing the backfill in a reasonable timeframe.
Testing Zero-Downtime Migrations
Zero-downtime migrations are more complex than traditional migrations and require more rigorous testing. Before applying any migration to production: test the complete migration sequence on a staging environment with production-scale data; verify that all deployed application versions work correctly at each stage of the migration; test the rollback procedure; and measure the time each step takes to establish realistic expectations for production execution.
Tools and Frameworks
Several tools can assist with zero-downtime migrations. Database migration frameworks like Flyway and Liquibase provide structured versioning for schema changes. Platform-specific tools like gh-ost (GitHub's online schema change tool for MySQL) can perform table alterations without blocking. Your cloud database provider may also offer online schema change capabilities.
Learn more about database migration strategies through our resources library, or contact us via our contact page to discuss your specific migration needs.