Build fluency in the vocabulary of safe, non-blocking database schema migrations.
0 / 5 completed
1 / 5
At standup, a dev mentions applying a database schema change, like adding a column, without locking the table or causing downtime for live traffic. What is this approach called?
A non-blocking schema migration, or online migration, applies a structural database change, like adding a column, without locking the affected table for reads and writes during the process, keeping the application fully available while the change rolls out. Traditional blocking migrations can cause noticeable downtime or degraded performance on a large, heavily used table. This non-blocking approach is especially valuable for production databases that can't tolerate scheduled downtime for routine schema changes.
2 / 5
During a design review, the team wants to test a risky schema change on an isolated copy of the production database before applying it for real. Which capability supports this?
Database branching creates an isolated copy of the production database's schema and data where a risky change can be tested safely, without any risk to the actual live database serving real traffic. This mirrors the same branching concept used in version control, applied to the database itself. It lets the team catch a problematic migration in an isolated environment before it ever touches production.
3 / 5
In a code review, a dev notices a proposed schema change must be explicitly reviewed and approved before it can be merged into the main database branch. What does this represent?
A schema change review workflow requires a proposed database structural change to be explicitly reviewed and approved before merging, mirroring the same code review discipline already applied to application code. This catches potentially risky or poorly considered schema changes before they reach the shared main database branch. Treating schema changes with this level of scrutiny reflects how significant an impact a database structure change can have on the whole application.
4 / 5
An incident report shows a schema change that dropped an unused column turned out to still be referenced by a legacy reporting job, breaking it in production. What practice would prevent this?
Auditing all real consumers of a database column, including less obvious ones like a legacy reporting job that isn't part of the main application codebase, before removing it catches exactly this kind of overlooked dependency. Assuming a column is unused just because the primary application no longer references it misses systems that read the database independently. This broader audit is an important step before any destructive schema change like dropping a column.
5 / 5
During a PR review, a teammate asks why the team relies on non-blocking schema migrations instead of scheduling brief downtime windows for routine database changes. What is the reasoning?
Scheduling a brief downtime window for a routine schema change requires coordinating around user impact and off-peak timing, which becomes increasingly difficult for an application serving traffic around the clock. A non-blocking migration avoids this coordination entirely by keeping the application available throughout the change. The tradeoff is that non-blocking migrations can be more complex to implement correctly for certain kinds of structural changes.