Skip to content

CONCEPT

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

  • — Taylor Barnett (PlanetScale, 2022-03-24). Origin-point source for schema revert as a feature. Launch-era limited-beta announcement. Canonical numbers: revert button available for 30 minutes after deploy, revert latency "in seconds" / "in less than a minute". Verbatim: "The ability to revert your database's schema changes in less than a minute with the press of a button with no downtime or data loss." Frames losslessness as a property of VReplication at MySQL transaction granularity. Doctrinal quote: "you can treat your database like you treat your code." Positions schema revert as the third pillar alongside branching and deploy requests.

  • sources/2026-04-21-planetscale-behind-the-scenes-how-schema-reverts-work — Holly Guevara & Shlomi Noach (PlanetScale). Canonical internals post. Explains the shadow-table-kept-alive mechanism, inverse-priming at cutover, and GTID-position anchoring. Pairs with the 2022 launch post: this one explains how schema revert works; the 2022 post explains what the product contract is (30-min window, seconds-scale SLO).

  • — 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."

  • — Shlomi Noach, PlanetScale, 2022-05-09. Canonical axiom-layer disclosure as tenet 8 of the operational relational schema paradigm and the single most deeply instantiated tenet across subsequent PlanetScale posts (three distinct mechanism canonicalisations: Barnett 2022-03-24 launch, Guevara+Noach 2022-10 internals, Noach 2024-09-04 30-minute-window refinement). Verbatim: "Schema migrations should be treated as first-class deployments. As such, the database system should be able to undeploy a migration, thus restoring the pre- migration schema. Developers should have the confidence that if a schema deployment goes wrong, they can revert it and go back to a known good state." Canonical framing: schema change must have parity with code deployment, including the operational safety-net of rollback. Noach published this principles essay in May 2022 — two months after Barnett's March 2022 launch post — making the paradigm document both retrospective (the feature already exists) and prescriptive (other databases must also adopt it).

  • — Canonical shortest-form customer-impact framing. Sam Lambert (PlanetScale CEO, 2023-06-28) frames schema revert as the tier-5 layer in PlanetScale's seven-layer data-safety envelope — and crucially as a data-safety primitive, not just a DX-nicety. Verbatim: "PlanetScale allows you to enable safe migrations, which protects against potentially destructive actions such as accidentally dropping a column or table. Safe migrations forces all schema changes to go through a deploy request, which is auditable, rate limited, and, most importantly, revertable. If you drop the wrong column or table, Revert allows you to instantly undeploy a schema change without any data loss. This turns multi-hour outages into a couple of seconds." The multi-hour outages → couple of seconds comparison is the canonical customer-impact framing: destructive DDL on a traditional database means restore-from- backup (hours); Revert makes it seconds because the former production table was kept alive as a ghost with inverse replication. Lambert adds three named properties to the deploy-request substrate: auditable (tracked change record), rate limited (can't accidentally batch-destroy), revertable (the Revert primitive). The rate-limited-ness is the novel datum — previous wiki framings emphasise auditability + revert, not rate limiting.

Last updated · 542 distilled / 1,571 read