Practice schema migration vocabulary: NOT NULL columns without defaults, backward-compatible migrations, zero-downtime changes, rollback vocabulary, and migration timing in production.
0 / 5 completed
1 / 5
A code reviewer flags: 'This migration adds a ___ column without a default.' Why is this dangerous?
Adding a NOT NULL column without a default value fails on non-empty tables because existing rows cannot satisfy the constraint. The fix is to add the column as nullable first, backfill data, then add the constraint in a separate migration.
2 / 5
The migration is ___ compatible: the old application version can still read the database during rollout.
A backward-compatible migration ensures that the previous version of the application continues to work while the new version is being deployed. This is essential for rolling deployments — old pods and new pods run simultaneously.
3 / 5
The ops team requires a ___ schema change for all production migrations. What does this demand?
A zero-downtime schema change uses techniques like adding nullable columns, online DDL, or multi-step migrations to avoid locking tables or restarting the database, keeping the application available throughout.
4 / 5
After a failed deployment the team executes the migration ___. What does this operation do?
A migration rollback is a prepared script (or automated reversal) that undoes the schema changes introduced by the migration. Not all migrations are safely reversible — for example, dropping a column cannot be rolled back without restoring data.
5 / 5
The deployment log shows: 'The migration ran in 14 seconds on ___.' Why does production timing matter?
'The migration ran in 14 seconds on prod' is a key data point because production tables are far larger than development or staging tables. A migration that takes seconds in testing may lock a production table for minutes, causing downtime.