Skip to content

CONCEPT Cited by 2 sources

Non-revertible schema change

Definition

A non-revertible schema change is a schema-change path whose execution does not build the substrate required for an automated, no-data-loss revert. The most prominent instance on the wiki is a PlanetScale instant deployment: because it uses MySQL's native ALGORITHM=INSTANT fast-path, it skips the shadow-table build that an Online DDL migration produces — and with no shadow table, there is no inverse-replication stream to play back for a revert.

The canonical framing comes from PlanetScale's own caveat on instant deployments:

"Instant deployments do come with some caveats: They are not [revertible]." (Source: sources/2026-04-21-planetscale-instant-deploy-requests)

The structural reason

The 30-minute revert window on a PlanetScale deploy is not a separately-implemented feature — it is an emergent property of how the Online DDL path works:

  1. Online DDL builds a shadow table with the new schema via VReplication.
  2. At cut-over, the forward stream is immediately re-primed in the inverse direction (new → old) and kept running.
  3. Every commit to the new table is projected through the DDL's inverse and applied to the old table.
  4. Revert is the same shadow-table cut-over played backwards — an instant table-swap, no data copy required, because the old table was being kept live all along.
  5. This inverse stream runs for a configurable retention horizon (PlanetScale's default: 30 minutes).

Instant deployments compress this entire substrate. There is no shadow table, no VReplication stream, no inverse projection. The DDL executes as a metadata- only change against the existing table in place. When a revert is requested, there is no substrate to play back.

The canonical wiki framing: revertibility is coupled to the execution path, not attached to the schema change as an independent property. An ADD COLUMN on a table via Online DDL is revertible; the same ADD COLUMN via instant deployment is not.

Revert options when the substrate is missing

When a non-revertible schema change needs to be undone, three options remain:

1. Compensating DDL

Apply an inverse DDL (ADD COLUMN → DROP COLUMN, MODIFY COLUMN SET DEFAULT x → MODIFY COLUMN SET DEFAULT y). This restores the schema but not the data — any rows written between the forward deploy and the compensating DDL reflect the intermediate-schema state, and any column values written into the added column are discarded on compensating drop.

The compensating DDL itself may or may not qualify for INSTANT — a drop of a column that was itself INSTANT-added typically does qualify. But the lock caveat from the forward deploy applies again on the reverse.

2. Restore from backup

Restores both schema and data from a backup point-in- time, but discards every write after that backup. For a table taking thousands of writes per second, the data-loss window can be hours. This is the same option that applies after an Online DDL's 30-minute revert window has expired.

3. Reconcile manually

Custom script to re-derive the column's values from other columns or upstream sources. Hours of engineering time per incident, and possible only when the data is recoverable (e.g. title derivable from an ADD COLUMN title AS CONCAT(first_name, ' ', last_name) forward deploy's inputs).

Data-loss asymmetry

Even a compensating-DDL revert of an instant deployment has the same column-projection asymmetry that the concepts/pre-staged-inverse-replication page documents for the Online DDL revert path:

Forward change Compensating DDL Data-loss on revert
ADD COLUMN x DROP COLUMN x Rows written post-forward lose any x values
DROP COLUMN x ADD COLUMN x Post-forward rows reappear with NULL (no historical x)
MODIFY COLUMN x SET DEFAULT a → b MODIFY COLUMN x SET DEFAULT b → a Rows inserted during the window use whichever default was active — not recoverable
CREATE TABLE t DROP TABLE t All rows written during the window lost
DROP TABLE t CREATE TABLE t All rows from the original table lost (no backup restore path)

The asymmetry is the same shape as Online DDL reverts after the 30-minute window — but on instant deployments it applies from the moment the deploy completes, because there is no window to work with.

When the non-revertibility is acceptable

Non-revertibility is an acceptable trade-off when the change is:

  • Forward-only by design — some changes are one-way regardless of mechanism. DROP COLUMN of a column with irreplaceable data cannot be cleanly reverted by any mechanism; forcing Online DDL on a change that has no meaningful revert path spends mechanism cost for zero benefit.
  • Tested on a branch first — PlanetScale's deploy-request workflow allows the change to run on a branch before production. If the branch-test passes, the revert probability is structurally low.
  • Additive and quickly compensable — ADD COLUMN with no concurrent writes to the column is cheaply compensable via DROP COLUMN, even without inverse replication.
  • Time-critical — if the alternative is a multi- hour Online DDL window blocking other operations on a queue, the loss of automatic revert can be worth the speed.

The patterns/instant-deploy-opt-in pattern canonicalises this trade-off as an operator-visible opt-in: PlanetScale surfaces the caveat explicitly rather than hiding it, so the operator can reason about which trade-off they're making per request.

Contrast with forward-migrate-only shapes

This concept canonicalises non-revertibility as a consequence of mechanism, not as a property of the change shape. It contrasts with schema changes that are intrinsically non-revertible (e.g. the DROP COLUMN of a column with data that cannot be reconstructed) — those are forward-migrate-only for semantic reasons. The two can compose — an instant DROP COLUMN is non-revertible for both reasons.

Seen in

Last updated · 378 distilled / 1,213 read