English for Database Migration Planning: Talk About Schema Changes Safely
Vocabulary and phrases for discussing database migrations in English: backfills, dual writes, downtime, rollback plans, and how to communicate risk to your team.
Database migrations are some of the riskiest changes an engineering team makes. A single bad schema change can lock a table, drop data, or take down production. Because the stakes are high, the planning conversations need precise English. This guide gives you the vocabulary and phrasing to discuss schema migrations safely and confidently.
Core vocabulary
| Term | Meaning | Example |
|---|---|---|
| Schema migration | A structural change to the database | ”This migration adds a nullable column.” |
| Backfill | Populating new columns/rows with historical data | ”We’ll backfill in batches overnight.” |
| Dual write | Writing to old and new schema simultaneously | ”We dual-write during the transition.” |
| Cutover | The moment you switch to the new system | ”Cutover is scheduled for Sunday 02:00.” |
| Rollback | Reverting to the previous state | ”We need a tested rollback path.” |
| Lock | When a table blocks reads or writes | ”The ALTER will take a long lock on a big table.” |
| Downtime | Period when the service is unavailable | ”We’re aiming for zero downtime.” |
The verb forms matter: you run a migration, backfill data, cut over to the new schema, and roll back if something breaks. Note “cut over” is two words as a verb, “cutover” one word as a noun.
Describing the change clearly
Start by stating what the migration does and whether it’s safe.
“This is an additive change — we’re adding a nullable column, so it’s backward-compatible and low risk.”
The opposite is a destructive or breaking change:
“Dropping that column is destructive. Once it’s gone, old app versions will break, so we need to roll it out in phases.”
Key safety adjectives:
- Additive / non-breaking / backward-compatible — safe, old code still works
- Destructive / breaking / irreversible — dangerous, can’t easily undo
- Online — runs without locking the table
- Blocking — holds a lock that stops traffic
“Postgres can add a column online, but adding a
NOT NULLconstraint with a default on an older version is blocking — it rewrites the whole table.”
The expand-contract pattern in plain English
Most safe migrations follow expand, migrate, contract. Being able to narrate this clearly is a sign you understand the risk.
“We’ll follow the expand–contract pattern. First we expand: add the new column and dual-write to both old and new. Then we backfill the historical rows. Once everything’s consistent, we flip reads to the new column. Finally we contract: drop the old column in a later release.”
Useful linking phrases:
- “First… then… once that’s stable… finally…”
- “We can’t drop the old column until every reader is migrated.”
- “There’s a transition window where both schemas coexist.”
Talking about risk and downtime
This is where diplomatic, precise English earns its keep. Don’t overstate or understate.
| Vague | Precise |
|---|---|
| ”It might be slow." | "The backfill could add significant write load for about two hours." |
| "It’s risky." | "The main risk is a long lock on orders, which has 200 million rows." |
| "We need to be careful." | "We should run this during the low-traffic window and have a rollback ready.” |
“Worst case, the backfill saturates the replicas and read latency degrades. To mitigate that, we’ll throttle the batch size and run it overnight.”
Phrases for managing expectations:
- “Worst case is X; most likely it’s Y.”
- “We’re aiming for zero downtime, but I’d budget a maintenance window as a fallback.”
- “This is a one-way door once we drop the column, so let’s be sure.”
One-way door (an irreversible decision) is excellent vocabulary for migrations.
Proposing a rollback plan
Reviewers will always ask “what’s the rollback?” Have an answer.
“If the cutover misbehaves, we flip the feature flag back and reads return to the old column. Since we’re still dual-writing, no data is lost. The only irreversible step is the final drop, which we won’t do for two weeks.”
Useful phrasing:
- “The rollback is clean up to the contract step.”
- “After the drop, there’s no easy way back — we’d restore from backup.”
- “We’ve rehearsed the rollback in staging.”
Before and after: a full rewrite
Before (alarming and vague):
“I want to change the database. It will maybe lock the table and be down for some time, I don’t know how much. We delete the old column. If problem, we restore backup.”
After (calm, structured, precise):
“I’m proposing an expand–contract migration on
orders. The expand step is additive and online, so no downtime there. The risky part is the backfill across 200M rows — worst case it adds two hours of write load, which we’ll throttle and run overnight. The cutover is a feature-flag flip, fully reversible. The only one-way door is dropping the legacy column, which we’ll defer for two weeks until we’re confident.”
Common mistakes
- Confusing “migrate” and “migration.” “Run a migration” (noun) vs “migrate the data” (verb). Don’t say “run a migrate.”
- Saying “it will be down” when you mean degraded. Distinguish full downtime from degraded performance.
- Translating false friends. In English, eventual means “happening at some point,” not “possible.” Say “eventual consistency” carefully — it’s a specific term meaning data converges over time.
- Forgetting the article with “rollback.” “We need a rollback plan,” not “we need rollback plan.”
Mini-glossary for the meeting
- Idempotent migration — safe to run more than once
- Shadow table — a copy you build alongside the live table
- Hot path — the most performance-sensitive code/queries
- Soft delete — marking a row deleted vs physically removing it
- Reconciliation — checking old and new data match
“Let’s run a reconciliation check after the backfill to confirm the two columns are in sync before we flip reads.”
Key takeaways
- Classify every change as additive/online (safe) or destructive/blocking (risky).
- Narrate the expand–contract flow with clear sequencing words.
- Quantify risk: “worst case X, most likely Y,” and always name the one-way door.
- Always have — and be able to describe — a rollback plan.
Speak about migrations the way you’d want a surgeon to speak about an operation: calm, specific, and reversible until the very last step.