Practise vocabulary for reviewing database schema changes in PRs: migration vocabulary, review comments, backward compatibility, and naming conventions.
0 / 5 completed
1 / 5
Adding a NOT NULL column to an existing production table without a default value is a ___ change — it will fail on all existing rows.
Adding a NOT NULL column without a default breaks existing rows (they'd have NULL in the new column, violating the constraint). Safe alternatives: add as nullable first, backfill, then add the NOT NULL constraint separately.
2 / 5
The safest pattern for renaming a column in a live production database is to ___.
Phased column renaming avoids downtime: (1) add new column, (2) write to both, (3) backfill, (4) update all readers to use new column, (5) drop old column. A single rename with active traffic causes immediate breakage.
3 / 5
A ___ migration modifies the schema without backfilling existing data — some rows will have the old structure until a separate job runs.
A lazy migration applies the schema change but doesn't immediately update existing rows. This is common for large tables where a full backfill would lock the table. Application code must handle both old and new data formats during the transition.
4 / 5
In schema review, 'this index is covering for the query' means the index ___.
A covering index includes all columns referenced by a query (in WHERE, JOIN, and SELECT). The database engine can satisfy the entire query from the index without touching the main table (heap), dramatically improving performance.
5 / 5
Using ___ as a primary key instead of natural keys (email, username) avoids issues when natural key values change.
Surrogate keys (UUID, SERIAL) are artificial identifiers with no business meaning. They never change, making schema evolution easier. Natural keys (email, username) can change, causing complex cascade updates.