How would you deploy a new container version that requires a database schema change while old and new replicas overlap?

Rolling container deployments with database migrations

Coordinates old and new application versions, expand-and-contract schema changes, migration ownership, readiness, and rollback during rolling releases.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

The expand release adds nullable columns, new tables, or compatible indexes first. Application code can then write both shapes or tolerate both while a bounded backfill runs. After every replica uses the new contract and data is verified, a later release removes the old column or behavior. This keeps rollback possible during the transition.

Full answer below

Practice focus

Rolling updates, backward compatibility, expand-and-contract, migration jobs, startup races, readiness, rollback, and observability.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A rolling deployment means old and new code run at the same time, so the database change must be compatible with both versions. I use expand-and-contract rather than making a breaking schema change in one step.
The expand release adds nullable columns, new tables, or compatible indexes first. Application code can then write both shapes or tolerate both while a bounded backfill runs. After every replica uses the new contract and data is verified, a later release removes the old column or behavior. This keeps rollback possible during the transition.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I do not let every replica race to run production migrations during startup. A controlled pipeline step or one migration job owns the schema change, reports status, and has appropriate locking. Readiness prevents new code from receiving traffic before required compatible schema exists, but startup should not hang indefinitely waiting for a dangerous migration. Large indexes and backfills are planned separately from a request-path rollout.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Dropping or renaming a column while old replicas still use it.
Running migrations independently from every starting replica.
Combining a large backfill with the application startup deadline.
Assuming image rollback also rolls back data.

How would you deploy a new container version that requires a database schema change while old and new replicas overlap?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement