Skip to content

CONCEPT Cited by 1 source

Schema revert

Definition

Schema revert is the operational primitive of undoing a deployed schema change while preserving the application-level writes that landed after the change was deployed. It is structurally distinct from naive "run the reverse DDL" — the reverse DDL trivially restores the old schema but may destroy the post-deploy writes (e.g. dropping a new column loses every value written to it since the deploy). Schema revert retains both the pre-deploy schema and the post-deploy writes by coordinating the revert at the ghost table altitude rather than the SQL altitude.

On PlanetScale, schema revert works by keeping the former production table as a ghost for a configurable window after the deploy, with inverse replication syncing post-deploy writes back into it. When the operator hits revert, the system "flips the statuses of the two tables, making the old production table active again, but it will contain the writes since the merge" (Morrison II, 2024). This is the canonical [[patterns/ instant-schema-revert-via-inverse-replication| instant-schema-revert-via-inverse-replication]] pattern.

Contrast with blue/green revert

Aurora blue/green has no equivalent: after switchover, the blue environment is stale (post-switchover writes landed on green). Reverting means accepting data loss or re-running a new blue/green deployment in reverse. The sibling post phrases this as a categorical design gap: "Amazon does not permit you to fail back in any way." (Morrison II, 2024.)

Seen in

  • sources/2026-04-21-planetscale-planetscale-branching-vs-amazon-aurora-bluegreen-deployments — Brian Morrison II (PlanetScale, 2024-02-02). Canonical wiki framing of schema revert as the reversibility primitive missing from Aurora blue/green. Verbatim: "PlanetScale databases support a feature called Schema revert, which will undo the changes made to the schema while still keeping any writes that occurred since the deploy request was merged. As mentioned, we use a ghost table to apply changes and sync the data between the live and ghost tables. With the Schema revert feature enabled, we retain the former production table for a period of time but continue to sync changes into it. When you revert the changes, our system will simply flip the statuses of the two tables, making the old production table active again, but it will contain the writes since the merge."
Last updated · 378 distilled / 1,213 read