VocalHyre
Sign up

CI/CD · Ship safely, repeatedly

How do you deploy database migrations without downtime?

Harddatabase migrationszero downtimeschemaUpdated Oct 2026
Quiz this track

Short answer

Use expand-and-contract: add a backward-compatible schema change, deploy code that writes both or tolerates both, backfill data in batches, then remove the old structure after all readers have moved.

Application code and schema changes cannot be deployed atomically in a distributed system. At some point old code runs against the new schema and new code runs against the old one, so both directions must be safe.

  • Expand: add nullable columns, new tables or indexes without breaking existing queries
  • Deploy: write to both old and new shapes, or make reads tolerant of both
  • Backfill: populate new data in small batches with throttling and progress tracking
  • Switch: move reads to the new shape and verify
  • Contract: remove old columns, triggers or dual writes only after every consumer has moved
sql
ALTER TABLE orders
  ADD COLUMN status_v2 text NULL;

CREATE INDEX CONCURRENTLY idx_orders_status_v2
  ON orders (status_v2);
A nullable column and a concurrent index avoid blocking writes on a large table.
Watch out for long locks, table rewrites and unbounded backfills. On large tables, use online schema-change tooling and batch updates with pauses so replication lag and lock contention stay controlled.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1Why can you not simply rename a column in one deployment?
  2. 2How do you backfill millions of rows safely?
  3. 3What is the contract phase and when is it safe?
  4. 4How do you roll back a migration that already ran?

Say it in the interview

I separate schema change from code change using expand and contract. First I add a backward-compatible structure, then deploy code that can read and write both shapes, backfill in throttled batches, and only later remove the old structure. That keeps old and new versions working during a rolling deploy. I also check lock behaviour and replication lag, because a migration that is logically safe can still take the database down.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

MediumWhat is your rollback strategy for a bad deployment?EasyHow should staging differ from production?MediumWhat deployment strategies are available and how do you choose?

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live CI/CD mock interview and get scored feedback on depth, clarity and confidence.

Start a free CI/CD interviewBrowse all questions