Is true zero-downtime possible for every schema change?

No. Some changes (e.g., shrinking VARCHAR length, changing column type incompatibly) require shims or multi-release choreography. The goal is zero user-visible downtime, not zero CPU pause. Use additive steps, views, and dual writes to emulate the new shape, then migrate gradually.

How do I handle column type changes safely?

Add a new column with the target type, backfill with `USING` expression logic in app code or batch job, dual-read under a flag, then switch and drop the old column. In Postgres, avoid `ALTER TYPE ... USING` on hot tables unless you’ve proven it’s lightweight.

What about multi-tenant or sharded databases?

Run the same expand–migrate–contract steps per shard with staggered rollouts. Canary 1–5% of tenants first, watch cross-shard metrics, and automate halt-on-lag. Keep playbooks shard-aware (connection strings, job distribution, and id ranges).

Do I need gh-ost or pt-online-schema-change on MySQL 8?

Often no—`ALGORITHM=INSTANT` and `INPLACE, LOCK=NONE` cover many cases. But for very large/hot tables or when server settings/DDL paths are unclear, gh-ost still gives safer, observable migrations with controlled cutover.

How long should I keep dual writes after flipping reads?

At least one full deploy cycle plus your longest data pipeline SLA (often 24–72 hours). Keep until you’ve validated metrics, backfills are done, and downstream consumers aren’t broken.

Guides · Oct 11, 2025 · 9 minute read

Zero-Downtime Schema Changes That Don’t Page You at 2 a.m.: The Expand–Contract Playbook That Actually Works

Stop praying before migrations. Here’s the proven, stepwise path to evolve schemas in production without brownouts, lock storms, or 3 a.m. rollbacks.

Back to all posts

Zero-Downtime Schema Changes That Don’t Page You at 2 a.m.: The Expand–Contract Playbook That Actually Works

Key takeaways

Implementation checklist