The Database Migration Strategy That Doesn't Take Down Your Production System

Database migrations strike fear into the hearts of engineers who’ve lived through bad ones. A migration that drops a column, renames a table, or changes a type with a running application connected to it is a high-risk operation that has produced real outages at real companies. But migrations don’t have to be scary — they just require a disciplined pattern.

The Expand/Contract Pattern

The foundational pattern for safe zero-downtime migrations: expand first, then contract. Expanding means adding new schema elements (columns, tables, indexes) while keeping old elements intact. Your application code then supports both old and new schema simultaneously. Once all application instances have deployed the new code, you contract — removing the old schema elements that are no longer needed.

Never Drop Columns in the Same Deployment

The most common migration mistake: dropping a column and removing the application code that references it in a single deployment. If the migration runs before the application deploys, the old code references a column that no longer exists. Always separate schema removals into their own deployment, after the application code that references them has been fully deployed and verified.

Backwards-Compatible Migrations as the Default

Every migration should be backwards-compatible with the current production application code. If a migration would break the currently-running application, it’s not ready to deploy. This rule eliminates the class of migration incidents where a deploy causes an immediate outage because the application and database schema are out of sync.