Skip to content

PlanetScale — Revert a migration without losing data

Summary

Taylor Barnett (PlanetScale, 2022-03-24) announces PlanetScale's schema revert limited beta — the product framing of the architectural primitive later detailed in Guevara & Noach's Behind-the-scenes post. Three concrete operational details anchor this launch post that the later deep-dive doesn't restate: (1) the revert button is available for 30 minutes after the deploy completes — the first explicit wiki-captured number for the schema-revert retention window; (2) the promise language is "in seconds" — the canonical product SLO for revert latency; (3) the causal chain is framed as VReplication operating at MySQL transaction granularity, i.e. the losslessness guarantee is a property of the transaction-level binlog tail, not a separate compensation layer. This is the origin-point post in the wiki's schema-revert corpus: 2022-03-24 launch, feeding the 2024-02-02 Morrison II Aurora blue/green comparison, the 2024-era Guevara/Noach internals post, and the broader deploy-request/branching workflow.

Key takeaways

  1. Schema revert is advertised as zero downtime plus zero data loss, in seconds. Quoting directly: "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." The marketing-language framing is structurally aligned with the later architectural explanation: seconds-scale revert is the surface expression of a pre-staged inverse-replication topology, not a separate rollback subsystem. (Source: sources/2026-04-21-planetscale-revert-a-migration-without-losing-data)

  2. 30-minute revert window is the operational SLA. Verbatim: "Any database enrolled in the limited beta will see a 'Revert changes' button available on the relevant deploy request page for 30 minutes after the changes have been deployed." This is the first wiki capture of the retention-window timing — the period during which the former production table is kept as a live-synced inverse shadow before the system tears it down. Everything at the cut-over altitude still works, but the revert button disappears after 30 minutes. (Source: sources/2026-04-21-planetscale-revert-a-migration-without-losing-data)

  3. Loss-lessness is a property of VReplication at MySQL transaction granularity, not a higher-level reconciler. Verbatim: "VReplication uses a lossless sync in the background between valid states of the database. It copies data from the source to the destination table in a consistent fashion. VReplication's implementation is unique because it allows us to go down to the MySQL transaction level, ensuring no data is lost and that your database schema returns to its previous state before the schema change." This frames the durability guarantee at the binlog-tail altitude — every committed transaction on the new table is replayed, transformed, and applied to the inverse-shadow old table before the revert swap happens. (Source: sources/2026-04-21-planetscale-revert-a-migration-without-losing-data)

  4. Revert retains post-deploy writes, including data from dropped columns. The post gives the canonical toy example: "if you remove a column and its associated data in a deploy request, and then revert it, your column and its associated data will appear again in seconds." This is the product-level articulation of the non-revertible schema change problem that plain reverse-DDL cannot solve. The pre-staged inverse stream holds onto the dropped column's values in the old-shadow table until revert-or-timeout. (Source: sources/2026-04-21-planetscale-revert-a-migration-without-losing-data)

  5. Schema revert is positioned as a third pillar of the PlanetScale workflow, alongside database branching and deploy requests. The post names the triad explicitly: "Along with existing PlanetScale features such as Database Branching and Deploy Requests, you can make changes (and fix changes) in your database faster and safer than before." The framing is that branching gives safe authoring, deploy requests give safe merging, and schema revert gives safe undo — treating the database with the same reversibility properties as source code. (Source: sources/2026-04-21-planetscale-revert-a-migration-without-losing-data)

  6. The "treat your database like you treat your code" doctrine is stated as the design intent. Verbatim: "It not only saves you time, but it makes schema changes less scary because you can treat your database like you treat your code. Unless you built custom in-house tooling for your database, these workflows have not been possible before." This is the earliest (2022) articulation of the developer-experience doctrine that Morrison II would sharpen two years later into the Aurora blue/green comparison. The claim is that pre-PlanetScale, only in-house-tool-heavy organisations (Facebook, GitHub, Shopify) had revert-capable database workflows. (Source: sources/2026-04-21-planetscale-revert-a-migration-without-losing-data)

  7. VReplication is reused across features — revert and Database Imports run on the same substrate. Verbatim: "This is possible because of VReplication in Vitess, the database clustering and management system that powers PlanetScale databases alongside MySQL. Vitess' VReplication also powers features like Database Imports." The post names the substrate reuse explicitly — reinforcing that VReplication is PlanetScale's canonical data-motion primitive, not a revert-specific mechanism. This matches later coverage: VReplication also powers resharding, MoveTables, materialisation, and online DDL. (Source: sources/2026-04-21-planetscale-revert-a-migration-without-losing-data)

Numbers and operational details

  • Revert window: 30 minutes after deploy completion. After that, the "Revert changes" button disappears and the inverse-shadow table is presumably torn down.
  • Revert latency: "in seconds" / "in less than a minute" — two phrasings in the same post for the product SLO.
  • Old-world baselines for comparison: "if you dropped the wrong index, running a new migration might take you a few hours to fix. Even worse, if you dropped the wrong column or table and had to restore from a backup, it would take days or weeks to roll out." The post is framing schema revert against these pre-existing alternatives (hours–weeks) to justify the seconds-scale claim.
  • Beta enrolment surface: database Settings tab → Beta features → "Enroll this database in the schema revert limited beta."

Caveats

  • Launch-post, not internals post. The mechanism is only sketched at high altitude (VReplication, transaction-level granularity, lossless sync). The Behind-the-scenes post (Guevara & Noach, later era) is where the shadow-table swap, inverse-priming at cutover, and GTID-position anchoring are explained. Use this source for the product-level contract (timing window, SLO, user flow) and the deep-dive for the architecture.
  • Limited beta at time of publication. Generally available as of later PlanetScale product generations. The 30-minute retention window may have evolved since the 2022-03-24 publication — treat as launch-era default, not immutable.
  • Pre-dates PlanetScale Postgres. This post is MySQL-only; the mechanism described rests on MySQL binlog semantics via Vitess VReplication. Whether PlanetScale Postgres has an equivalent primitive is unstated here.
  • Tier-3 launch post. Body is mostly marketing prose; architectural content is ~20–25% (one paragraph on VReplication, one example, one triad framing). Included on the strength of the operational numbers (30-min window, seconds-scale SLO) and its position as the origin-point of the schema-revert corpus.

Source

Last updated · 470 distilled / 1,213 read