Skip to lesson
Exit
CI/CD, release engineering & the toolchain1 / 2

2 min lesson

The rollback truth: schema constrains everything

Explain your answer to "Why do database migrations constrain rollback and what is the expand/contract pattern?" Add one concrete detail from the lesson.

Step 1 of 2

The rollback truth: schema constrains everythingthe senior signal

Application code rolls back cleanly. Database migrations do not. Once a migration drops a column or changes a type, rolling the app back to a version that expects the old schema can corrupt data or crash the service. This is the single most common place a naive rollback story falls apart and naming it is how you signal seniority.

The pattern that fixes it

Expand/contract (a.k.a. parallel-change): Expand the schema to support both old and new code. Add the new column, then backfill and dual-write. Deploy code that reads new and tolerates old. Only contract, dropping the old, once nothing references it, often a release or two later.

This is why mature teams decouple deploy from release and, for schema changes, prefer roll-forward over rollback. You can't un-drop a column, but you can always ship a forward fix.

  1. 1Expand: additive migration only, such as a new nullable, backfilled column or table. Backward compatible.
  2. 2Migrate code: deploy an app that writes both and reads new with fallback. Now it's safe to roll back the app, because the schema still supports old code.
  3. 3Release: flip the flag to use the new path for real users.
  4. 4Contract: in a later, separate change, remove the old column once no code path touches it.
Watch out

A destructive migration coupled into the same deploy as the code that needs it is a one-way door. You've thrown away your rollback. The fix is sequencing, not heroics.

Cursor is genuinely useful here. It generates the paired expand and contract migrations, the dual-write code and the tests for both states, turning a discipline most teams skip into something cheap enough to actually do. On Teams and Enterprise, Cursor's Rollouts bot watches each PR after deploy and reports verified healthy, regression detected or inconclusive per environment. It does not roll back on its own today; it can open a revert PR for a human to merge.

Learn more

Full explanation

Full explanation

Say it like this

"Code rolls back. Schema rolls forward. So we expand-contract, decouple deploy from release and keep a roll-forward fix one small PR away. Cursor makes writing the paired migrations and dual-write code cheap enough that teams actually do it."

Learn more

Optional practice

Test yourself on The rollback truth: schema constrains everything

QA team does blue/green deploys and believes they have instant rollback for everything. What's the hidden risk?