CONCEPT Cited by 1 source

Reverse-order revert¶

Definition¶

Reverse-order revert is the property that undoing a multi-migration schema deployment by applying each migration's revert in the inverse of the original deploy order mathematically preserves schema validity at every step — no separate dependency analysis is needed for the revert; the ordering falls out of symmetry with the forward deployment.

Canonical verbatim framing:

"Notably, the reverts are finalized in reverse ordering to the original deployment. There is no need for computation here: we rely on the fact that the original deployment was found to have a step-by-step valid ordering. Undoing those changes in reverse order mathematically maintains that validity."

(Source: sources/2026-04-21-planetscale-deploying-multiple-schema-changes-at-once)

Why it works¶

If the forward deployment was executed in the order D_1, D_2, ..., D_N and schemadiff verified that the schema remained valid after each step D_i, then the sequence of schema states is:

S_0 → S_1 → S_2 → ... → S_N

where S_0 is the original schema and S_N is the post-deployment schema, each arrow a valid DDL transformation.

The reverse sequence S_N → S_{N-1} → ... → S_0 is provably valid by construction — every pair (S_i, S_{i-1}) represents the undo of a known-valid forward step. If D_i transitioned S_{i-1} to S_i validly, then D_i^{-1} transitions S_i to S_{i-1} through a validity-preserving sequence (the schema was valid at both endpoints, so the intermediate computation cannot surface a novel validity violation).

Crucially, this property does not require schemadiff to re-plan the revert. The reverse order is a mathematical consequence of the forward order being validity-preserving.

Composition with inverse replication¶

Reverse-order revert is the cross-migration validity property; it composes with instant schema revert via inverse replication, which provides the per-migration data-preservation property.

The 30-minute revert window works because:

Per migration: [[concepts/pre-staged-inverse- replication|pre-staged inverse replication]] keeps the old-schema table continuously updated with every post- cut-over write on the new-schema table. Reverting one migration is a second cut-over that swaps them back — no data lost.
Across migrations: reverse-order revert ensures the cross-migration dependency graph is respected during the revert. If migration M_A added a view depending on a column added by M_B, the original deploy sequenced M_B before M_A; the revert sequences M_A^{-1} before M_B^{-1}, which is still valid (drop the view, then drop the column).

Without reverse-order revert, reverting N migrations would require schemadiff to re-compute equivalence classes on the inverted diff set — doable, but redundant given symmetry.

Without inverse replication, reverting a single migration would lose all writes that landed in the new schema post- cut-over — so reverse-order revert alone is not enough.

Both together give the "30-minute window to undo those schema changes without losing data accumulated" — the canonical product promise that makes schema changes on PlanetScale "cancellable up to the very last moment and without making any impact on production."

Why the 30-minute window¶

The post specifies 30 minutes as the revert window. The window is bounded because inverse replication (the per-migration mechanism) continues to hold resources: the old-schema table stays live, binlog tailing continues, and operational cost scales with staged migrations × window duration. Thirty minutes is PlanetScale's chosen cap balancing rollback flexibility against steady-state cost.

After the window closes, the inverse replication streams are torn down. A revert at that point requires authoring a new forward migration — no longer free, no longer data-preserving in the pre-staged sense.

Relationship to equivalence classes¶

Reverse-order revert is compatible with equivalence-class parallelism. Different equivalence classes are independent in both directions — cross-class cut-overs can happen in arbitrary order, so cross-class reverts also have no ordering constraint. Within each class, the forward order was topologically sorted; the reverse order is topologically valid by the same argument.

Seen in¶

sources/2026-04-21-planetscale-deploying-multiple-schema-changes-at-once — canonical wiki disclosure. Shlomi Noach: "When all migrations are complete, PlanetScale then stages tentative reverts for all migrations. The user has a 30-minute window to undo those schema changes without losing data accumulated... those reverts are likewise applied near-atomically. Notably, the reverts are finalized in reverse ordering to the original deployment." The "mathematical maintenance of validity" argument is explicit — symmetry as a first- class correctness primitive.