Problem
Schema changes (add column, rename, split table) lock tables, break running apps, cause downtime.
data-consistencyestablished · high operational burden
Database Migration (Expand/Contract)
Also known as: schema-migration, expand-contract, zero-downtime-migration
Intent
Evolve database schema without downtime or locking, using backward-compatible multi-phase migrations.
Forces
- •Applications deploy independently of database
- •Old and new code run simultaneously during rollout
- •Rollback must not require database rollback
- •Large tables: migrations take hours, cannot lock
Solution
✓ When to Use
- •Any schema change on tables with >1M rows
- •Zero-downtime deployments required
- •Blue-green or canary deployments
✗ When Not to Use
- •Small tables, maintenance window acceptable
- •Breaking changes that can't be phased (rare)
- •Team not ready for migration discipline
Pros
- +Zero downtime, zero lock
- +Instant code rollback at any phase
- +Data migration decoupled from deploy
- +Auditable, repeatable
Cons
- −4+ deploys for one logical change
- −Temporary schema complexity (old + new)
- −Migration scripts must be idempotent, resumable
- −Contract phase irreversible
Cost Profile
Infrastructure
Low — migration tools, temp storage
Operational
High — multi-phase, verification, timing
Cognitive
High — expand/contract discipline
Failure Modes
Backfill stalls → phase 3 delayed
Data inconsistency between old/new → silent corruption
Contract before verification → data loss
Index creation locks table (use CONCURRENTLY)
Migration script bug → partial state, manual fix
Real-World Examples
Alternatives
- maintenance-window
- shadow-table
- cdc-based-migration
Related Patterns
- blue-green-deployment
- canary-deployment
- cdc
- outbox-pattern
- versioning
Competency Domains
data statedeploymentreliability opseconomics evolution