PLANETSCALE 2022-05-09 Tier 3

PlanetScale — The operational relational schema paradigm¶

Summary¶

Shlomi Noach's canonical principles essay on what a modern relational database ought to offer around schema change — the axiom layer beneath PlanetScale's entire subsequent deploy-request / instant-deploy / schema-revert corpus. Written 2022-05-09, this post is not an architecture disclosure but a manifesto: it enumerates ten tenets Noach argues are essential for schema migrations in production databases, frames them against the historical status quo ("thirty years ago, developers would plan a schema change months ahead"), and positions each as a gap in off-the-shelf relational databases that PlanetScale / Vitess / gh-ost together answer.

Canonical opening frame:

"Today, those maintenance windows are unacceptable to most organizations. … today's developers are used to accelerated deployment flows and want to continuously deploy schema changes, also known as schema migrations, sometimes multiple times per day. But relational databases have not stepped up to meet developers' needs."

The essay is dense with canonical verbatim framings and zero architecture-diagram content. Its wiki value is as the source-of-truth disclosure of the ten operational-paradigm tenets that every subsequent Noach ingest references implicitly: instant-deploy (2024-09-04) extends tenet 1 (non-blocking) + tenet 10 (idempotent) into a fast-path; schema-revert (2022-10, Guevara/Noach) is the productised form of tenet 8 (reversible); gated-deployments (2024, Noach) extends tenet 4 (scheduling). This is the foundational philosophy post on PlanetScale's schema-change model.

Key takeaways¶

Historical framing — schema changes took months.

"Thirty years ago, developers would plan a schema change months ahead. One would only deliver a handful of changes a year. Developers would work with the database administrators to approve schema changes and plan the transition into the new model. Companies would take the system down for maintenance, sometimes for hours or days, to apply those changes." Canonical opening framing for why the paradigm needs reinvention — the pre-CI-CD schema-change model is structurally incompatible with "continuously deploy schema changes … sometimes multiple times per day."
Root-cause framing — relational databases are the laggard primitive. Verbatim: "Schema deployments for large tables frequently remain a manual endeavor and are considered risky operations. … developers regard relational databases unlike other production systems and evolve patterns to try and minimize schema migrations or avoid them altogether by modifying their code in suboptimal manners." Canonical framing: the structural treatment of schema as an immutable crust in application design is a symptom of the database's operational deficit, not a virtue. "We believe this to be the result of negligence; that relational databases can and should meet modern development practices for schema deployments, thus allowing for more automation, control, velocity, and, as result, confidence in the process."
Tenet 1 — Non-blocking migration. Verbatim:

"Some relational databases, and for some types of schema migrations, place a write lock on the migrated table, effectively rendering it inaccessible to the app. This in turn commonly manifests as an outage scenario. An ALTER TABLE migration for large tables can be measured in hours or even days. These blocking migrations are unacceptable to modern development flows and modern apps, and databases must offer non-blocking migrations that allow full access to the migrated table throughout the operation." This is the foundational tenet — canonicalised on the wiki as Online DDL / non-blocking migration and as the prior-art taxonomy framing (shadow-table via gh-ost / pt-online-schema-change) that Lucy Burns's 2021-05-20 Non-blocking schema changes launch post named as the mechanism.
Tenet 2 — Resource-aware migration (yield to the app). Verbatim:

"Even when available, non-blocking schema changes are typically aggressive in resource consumption and will attempt to utilize as much disk IO operations, memory, and CPU to run to completion. This competes with resources needed by the apps and often leads to degraded app performance. Schema changes should be able to yield to the app's needs." Canonical predecessor of the traffic-aware migration throttling concept — Noach's 2024-08-29 Anatomy of a throttler Part 1 canonicalises the mechanism (the Vitess throttler fed by pt-heartbeat replication-lag measurements); this 2022 essay canonicalises the principle (migrations must defer to OLTP).
Tenet 3 — Asynchronous migration. Verbatim:

"Atomic or transactional migrations are appreciated, but they imply a connection to be held active for the duration of the migration, which we measure by hours or days. Deployment tools, or even scripts, should not be required to hold on to those connections for such long periods. The behavior upon connection loss is normally not what the developer wants. Databases should be able to receive a schema change request and move to run it asynchronously." Canonical tenet: the schema-change submission must be decoupled from the schema-change execution — a client submits a deploy request, disconnects, and the database system runs the migration to completion on its own timeline. This is the architectural justification for the deploy-request primitive: it is not just a PR analog; it is the async execution handle for a long-running operation where the client-side connection lifecycle does not gate the migration.
Tenet 4 — Schedulable migration. Verbatim:

"Migrations may conflict with each other, either due to running on the same tables or simply because of the excessive resource consumption incurred. Databases should provide a mechanism for scheduling migrations. The database should be able to determine which migrations are safe to run concurrently and which are not." Canonical predecessor of the schema-change queue (which Burns 2021 canonicalised as the serialised one-at-a-time queue) and the pre-flight conflict check (which Burns 2021 canonicalised as the three-check pipeline). This 2022 essay frames the principle: the database itself must own migration scheduling, not leave it to human operators.
Tenet 5 — Interruptible migration. Verbatim:

"Even if lightweight, a migration still has an impact and footprint. Disk space and disk I/O operations are most notable. It is sometimes required to stop that impact. It should be possible to interrupt a running migration at no immediate cost. A several hour long rollback or flushing of pages are examples of undesired cost, at a time resources are needed the most." Canonical tenet: the migration must be cleanly cancellable — no multi-hour rollback, no page-cache flush, no resource thrash — at the moment when operators most need headroom. Ties to Noach's subsequent cancel- before-cutover canonicalisation in the Gated deployments post.
Tenet 6 — Migration ETA / progress estimate. Verbatim:

"The database should be able to provide an estimate of a long migration's progress or ETA." Shortest tenet in the post. Canonical framing: a multi-hour migration without progress telemetry is operationally opaque — operators need to know "how far through are we" to decide whether to cancel (tenet 5), throttle (tenet 2), or let run. Not deeply canonicalised elsewhere on the wiki as a standalone concept — the tenet frames a capability rather than a mechanism.
Tenet 7 — Failover-agnostic / resumable migration. Verbatim:

"A database should be able to resume a migration interrupted due to database failure. As an example, it should be possible for an operator to reboot the database server without compromising a days-long migration. The same is true for unexpected failures. Operations teams should not postpone maintenance work due to developer's deployments, and developers should not withhold deployments due to planned operations. If a database offers a multi-node design, i.e., a cluster of nodes, then migrations should be agnostic to cross-node failovers and should not be bound to the specific node where they started." Canonical tenet: migration state is persisted outside the ephemeral process running it, so reboots / failovers / node loss do not abort in-flight migrations. This is the architectural basis for gh-ost's and Vitess's use of a durable migration-state ledger (the _vt_schema_migrations table) that any tablet can pick up and continue.
Tenet 8 — Reversible migration. 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 predecessor of the schema revert primitive + instant-revert-via-inverse-replication pattern. Guevara + Noach's Behind the scenes: how schema reverts work (2022-10) canonicalises the mechanism (inverse VReplication from the kept shadow table back to the original); this 2022-05 essay canonicalises the principle 5 months earlier. Noach's 2024-09-04 Revert a migration without losing data extends with the 30-minute revert window and the preservation of post-cutover writes. This is the single tenet most deeply instantiated on PlanetScale across three subsequent posts.
Tenet 9 — Idempotent migration. Verbatim:

"Much like code deployments, schema deployments should be idempotent. The developer or the deployment system should be able to submit the same migration request twice (or more) in a row, and the database should resolve the excessive requests to ensure the migration runs once, as the developer would expect." Canonical tenet: deploy-request submission is safe to retry. Operational: if a deployment tool is uncertain whether a submission succeeded (network partition, timeout, ambiguous response), it can re-submit; the database deduplicates. The companion to Tenet 10 — both enable declarative tooling to submit desired-state repeatedly without triggering double-apply.
Tenet 10 — Declarative schema deployment. Verbatim:

"Databases should potentially support declarative schema deployments, where a developer submits a desired state rather than an imperative command. Declarative schema deployments are idempotent by nature." Canonical framing: declarative supersedes imperative for schema change — submit CREATE TABLE users (...) as the desired end-state and let the database compute the diff + generate the migration, rather than author the ALTER TABLE sequence manually. Canonicalised on the wiki as schema as code + declarative schema management, instantiated by the Atlas CLI tutorial posts (Morrison II, 2022 + 2023). Noach's tenet argues the declarative substrate belongs in the database, not in an external tool — a framing the Morrison II Atlas posts do not share. Ties to Vitess's schemadiff library which implements the diff-compute primitive for the declarative path (see Noach 2024 Deploying multiple schema changes at once).
Closing synthesis — confidence as the product. Verbatim:

"With these principles in place, developers have the confidence that their schema migrations will not put substantial load on production servers. That their deployment tools will not have to block for hours while running the change. That the database will gracefully schedule their migration while other deployments are in place. They can track the progress of the migration at any time and interrupt it if the need arises, at no additional cost." And: "Developers are free from operational considerations." The canonical product framing: the ten tenets converge on developer confidence as the output metric — the schema change feels like a code deploy because all the operational baggage has been absorbed by the database layer. "These all suggest a relaxed development flow that gives developers ownership of their schema changes and the confidence to deploy with velocity."

Systems¶

PlanetScale — the managed platform that Noach argues instantiates all ten tenets. This essay is the philosophical charter of PlanetScale's schema-change product surface.
Vitess — the sharding + orchestration substrate underneath PlanetScale that owns the deploy-queue execution, failover-agnostic migration state, and the schemadiff declarative engine.
gh-ost — the non-blocking migration tool that satisfies tenets 1, 2, and 7 at the mechanism altitude; called out by Burns 2021 as the engine under PlanetScale's workflow.
MySQL — the target engine whose native ALTER TABLE behaviour the essay critiques (blocking, hours-to-days, no ETA, not resumable).

Concepts¶

Operational relational schema paradigm — new wiki concept — the ten-tenet framework itself as Noach's canonical name for it.
Online DDL — tenet 1 at the mechanism altitude.
Traffic- aware migration throttling — tenet 2 at the mechanism altitude.
Deploy request — tenet 3 instantiated as the async-execution handle primitive.
Schema-change queue — tenet 4 at the mechanism altitude.
Pre-flight schema-conflict check — tenet 4's safety precondition.
Cancel before cutover — tenet 5 at the mechanism altitude.
Schema revert — tenet 8 at the mechanism altitude.
Schema as code — tenet 10 at the adjacent-altitude external-tool framing.
MySQL ALGORITHM=INSTANT — a partial satisfaction of tenet 1 by the engine itself (no rewrite, fast path).

Patterns¶

Branch- based schema-change workflow — the overarching PlanetScale product pattern that wraps all ten tenets in a developer-facing workflow; canonicalised by Burns 2021.
Shadow- table online schema change — gh-ost / pt-osc mechanism that satisfies tenets 1, 2, 5, 7.
Instant schema revert via inverse replication — the mechanism that satisfies tenet 8 with the PlanetScale-specific 30-minute window + preservation of post-cutover writes.
Declarative schema management — tenet 10 instantiated by external tools (Atlas, Skeema).

Operational numbers¶

Schema-change cadence then vs now — "Thirty years ago, developers would … only deliver a handful of changes a year … maintenance windows of hours or days" vs today's "multiple times per day." Canonical before/after framing.
ALTER TABLE duration on large tables — "hours or even days" — the native-MySQL performance anchor Noach critiques.
Async-migration connection-hold duration — "hours or days" for atomic/transactional migrations without the async primitive.
No new numbers of PlanetScale's own performance — this is a principles post, not a measurement post.

Caveats¶

Manifesto / principles essay, not architecture disclosure. The post enumerates a design philosophy; it does not walk an implementation. Wiki value is as the foundational axiom-layer post beneath the subsequent deploy-request / instant-deploy / schema-revert mechanism posts. Treat it as the charter document of PlanetScale's schema-change product surface.
Tenets are not numbered in the original post. The essay enumerates them in prose paragraphs without numbers; the wiki's 1–10 numbering is editorial (for cross-reference), not Noach's. Noach's order is preserved.
No competing-approach engagement. The essay critiques the status quo (native ALTER TABLE, Liquibase / Flyway manual flows) but does not engage alternative designs (e.g. CockroachDB's online schema change, Spanner's schema-version vector, Vitess's own schemadiff vs. Atlas's HCL). The implicit claim is "PlanetScale satisfies all ten; nothing else does" — load-bearing for the product argument but not defended comparatively.
Tenet-vs-mechanism coupling not claimed uniformly. Tenet 6 (ETA) has no canonicalised wiki mechanism; tenet 8 (reversible) has three subsequent posts with deep mechanism canonicalisation. The asymmetry reflects which tenets PlanetScale invested deepest in productising after this essay.
Declarative-vs-imperative framing (tenet 10) is contested in practice. Morrison II's companion Atlas-CLI tutorial (2022-09-16) and declarative- migrations explainer (2023-04-05) canonicalise the declarative path as an external-tool workflow on top of PlanetScale, explicitly flagging that PlanetScale's native safe-migrations feature must be disabled to use Atlas — i.e. Atlas and PlanetScale's native deploy-request workflow are rivals on the declarative substrate. Noach's tenet 10 frames the substrate as belonging in the database; Morrison's posts frame it as an adjacent tool choice. The tension is unresolved on the wiki.
2022-era publication. The essay predates instant-deploy (2024-09-04), the 30-minute revert window (2024-09), gated deployments (2024), Vitess 21 atomic distributed transactions (2024), and PlanetScale-for-Postgres (2025-07). The tenets generalise across those extensions but the essay itself does not discuss them.
No Noach authorship framing. The post is attributed to "Shlomi Noach" at the top but without bio. Noach is the ex-GitHub engineer who created gh-ost — critical for tier-passing voice analysis. This essay is him laying out the paradigm his career has been building toward; the tenets map directly onto gh-ost's design goals (async, non-blocking, resumable, interruptible, throttled) extended to the schema-change-as-deploy-request layer PlanetScale adds on top.