Backend Developer interview question
How do you ship database migrations safely?
Ship migrations in compatible steps: add first, deploy code that handles both shapes, backfill safely, switch reads, then remove obsolete fields later. Keep locks and transactions short.
Direct answer
What a strong answer covers
How it works
A safe migration never requires the schema and the code to change at the same instant. Every step must work with both the previous and the next version of the application: expand the schema, deploy code that writes both shapes, backfill in small batches that do not hold long locks, switch reads, and only then contract by dropping what is unused. Each step gets its own deploy and its own rollback, and operations that rewrite a whole table or take an exclusive lock are checked against the engine’s behaviour before they run in production.
Example
Add a nullable column, deploy writers for it, backfill in batches, make it required only after every live version can read it. Renaming a column becomes add new, dual-write, backfill, switch reads, stop writing old, drop old, across several releases rather than one ALTER that breaks the running pods.
Common mistakes
- Running a NOT NULL or type change on a large table in one statement and locking it for minutes.
- Coupling the migration to the deploy so a rollback of the code leaves the schema ahead of it.
- Backfilling with a single UPDATE that bloats the table and floods replication.
A useful answer structure
Answer from your own work.
Do not memorise a script: use only examples you can explain honestly in follow-up questions.
Open the desktop workspace and rehearse a clear answer in your own words.