Skip to content

PLANETSCALE 2021-07-13 Tier 3

Read original ↗

PlanetScale — The promises and realities of the relational database model

Summary

Shlomi Noach's 2021 framing essay arguing that the relational model's operational weakness is schema change, not read/write performance — and that this weakness, not NoSQL's technical superiority, is the reason developers flee relational databases. Written 2021-07-13, this post is the prequel to Noach's better-known 2022-05-09 operational relational schema paradigm manifesto: same author, same thesis, ten months earlier, and pitched one altitude lower — it names the problem shape that the later post enumerates as a ten-tenet solution specification.

Canonical opening frame:

"The relational model — tables with a predefined set of typed columns and with cross table references — is one of the oldest surviving models in computer science and in real life deployments. It's rare to see models that survive decades of software evolution. This survival suggests that the model is sensible, practical, and solid."

Canonical load-bearing claim:

"while database systems optimize for read/writes, they do not optimize as much for metadata changes. And most specifically to schema changes."

Canonical causal claim:

"I believe the issue of schema management is one of the major reasons to push developers away from the relational model and into NoSQL solutions."

The post enumerates the operational tax a developer pays to ship a schema change in production MySQL (understanding metadata locking / gh-ost / pt-online-schema-change invocation / throttling configuration / error handling / coordination with concurrent migrations) and then names four developer workarounds observed in the wild when this tax is too high: (1) stall and aggregate changes into one deploy; (2) overload schemaless JSON columns; (3) avoid schema changes and write suboptimal code; (4) leave the relational model entirely for a document store.

It closes with the thesis that reducing the operational friction around schema change is how PlanetScale justifies its existence — not replacing the relational model but finally making it deploy-compatible with modern development flows.

Key takeaways

  • The relational model survived for a reason. Noach opens with the model's durability — "decades of software evolution" — as evidence it solves the organise-data-into-entities-and-relationships problem well. The structural argument is that the data model is fine; the operations on it are the problem. This framing is load-bearing: if the data model were wrong, NoSQL would be the correct fix; because it isn't, the fix lives one layer up at the operational interface.

  • The weakness is metadata, not read/write.

    "database systems optimize for read/writes, they do not optimize as much for metadata changes. And most specifically to schema changes." Canonicalised as concepts/schema-change-operational-friction. First-class framing: schema change isn't slow because ALTER TABLE is slow (it frequently is), it's slow because the workflow around a schema change is slow — discussions, privileges, tool choice, throttling, monitoring, recovery, coordination, scheduling — and none of that is in the data path. The operational cost scales with team size, not table size.

  • Schema change was historically not in the data path.

    "Back in the old days, schema changes were not so frequent. We didn't have the internet, and products would evolve to the next version over months. DBAs commonly acted as gatekeepers to the database … The change itself was not considered to be in the data path. You'd, for example, take the system down for scheduled maintenance, run a series of schema changes, bring the system back, and repeat every few months." Same historical before-frame that Noach reprises in the 2022 paradigm essay; here it's positioned as the structural reason relational databases never invested in operational schema tooling — they were built for a deployment model where schema change was a planned downtime, not a continuous release.

  • Today the contract inverted; the database didn't.

    "Today, it's not uncommon for popular services to run multiple schema migrations per day." Product velocity (multiple migrations/day), operational tolerance (maintenance-window outages not acceptable), and org structure (DBA-as-enabler not gatekeeper) all flipped. The relational database's operational model did not. Canonicalises concepts/continuous-schema-deployment as the new contract.

  • The operational tax is concrete and enumerated. The post names six specific skills a developer must acquire to ship a MySQL schema change in production: (1) understand metadata-locking semantics + replication lag + resource-exhaustion failure modes; (2) know where in production the target table lives (which primaries serve it); (3) know gh-ost or pt-online-schema-change (both referenced by name); (4) configure throttling; (5) observe and monitor progress; (6) clean up artifacts. Plus error handling (internal DB errors, tooling errors, mid-migration failover scenarios) and coordination (sequence migrations; don't collide with peers). This is the ambient cost of "schema change" in 2021 MySQL — canonicalised as concepts/schema-change-operational-friction.

  • Coordination reinstates the DBA as gatekeeper.

    "The operational expertise illustrated above, along with the need to synchronize changes, reinstates the DBA as the database's gatekeeper. This time as a forced constraint." Canonicalised as concepts/dba-as-forced-gatekeeper. First-class structural observation: it's not culture pushing DBAs back into gatekeeper roles at growing companies, it's the absence of a database-native scheduler / conflict-resolver / failure-handler. Someone has to own serialisation of migrations; if the database doesn't, a human does. The gatekeeper role is a structural shape, not a political choice.

  • Four developer workarounds when the tax is too high. Canonicalised as concepts/developer-schema-workarounds. Verbatim from the post:

    "Stalling development and aggregating multiple changes into single deployments. Overloading schema-less JSON columns with more content. Avoiding schema changes and tweaking the code in a non-optimal fashion. Moving away from relational databases and into document stores, trading off the advantages of RDBMS for faster deployments." Four anti-patterns, ranked by increasing distance from the relational ideal. The last — fleeing to document stores — is the one the industry conversation usually frames as "NoSQL is better for velocity"; Noach's reframe is "NoSQL is chosen because schema change operationally sucks, not because the document model is structurally superior." This is the load-bearing claim of the entire post.

  • JSON column as escape hatch is an anti-pattern. Canonicalised as concepts/json-column-as-schema-escape-hatch. The developer-reached-for reason is operational: a JSON column's values can change shape without a schema migration, sidestepping the entire operational apparatus. The cost is that every future query gains a dimension of uncertainty — no type enforcement, no schema-validation at write, no query planner visibility into shape, no migration path for JSON-embedded structure that later wants to become a column. The anti-pattern is "within-cell schema evolution" — using the row-value boundary to escape the metadata layer.

  • A schema change is a code change that doesn't feel like one. Noach frames the asymmetry verbatim:

    "A RDBMS schema change is an alien operation for many developers. It feels nothing like a code deployment. It does not enjoy the level of automation the developers come to expect of code. There is no conflict resolution mechanism to deal with rapid developments across large teams. The risk to production is high and the database does not offer a mechanism to undeploy your changes." This is the prescriptive frame for the entire post-2021 PlanetScale corpus: make schema change feel like code change. Canonicalises patterns/developer-owned-schema-change as the goal state — code-review-style review, CI-style validation, git-style conflict resolution, deploy-style rollout, revert-style undeploy, all owned by the developer without DBA mediation.

  • The closing thesis names PlanetScale's reason for existing. Verbatim closing:

    "These are some of the things we had in mind while developing PlanetScale. We believe the relational model is solid, and that reducing its operational friction goes a long way. We wanted to create a developer friendly experience that also gives back the developers ownership of their changes. We believe this experience can give developers joy." The whole PlanetScale product (branching + deploy requests + schema revert + throttled online migrations

  • conflict pre-flight) is the instantiation of this paragraph. Every subsequent PlanetScale schema-change ingest on the wiki is a mechanism realising this framing.

Operational numbers / diagrams

None. This is a 2021 framing essay, not a mechanism disclosure. Zero architecture diagrams, zero benchmarks, zero production telemetry, zero code. The post's value is its canonical naming of the problem shape that later mechanism posts solve.

Third-party tools referenced by name (without spec): - gh-ost — Noach himself created gh-ost at GitHub in 2016; the post doesn't name him as the author, but the reference is load-bearing: gh-ost is the mechanism Noach ships with to PlanetScale a few years later. - pt-online-schema-change (Percona Toolkit) — trigger-based online schema-change tool; sibling mechanism to gh-ost. Both implement the shadow- table online schema change pattern.

Caveats

  • Framing essay, not mechanism disclosure. No architecture diagram, no code, no production numbers. Value is as a canonical problem-shape article, not as a deep-dive.
  • MySQL-specific enumeration. The six-skill operational tax enumeration is written for MySQL + gh-ost / pt-online-schema-change; Postgres's pg_repack / pg_online_schema_change / logical replication + dual-write equivalents aren't engaged. The generalisation to "relational databases in general" is partially earned — Postgres has its own operational taxes, different in shape but similar in total friction.
  • NoSQL framing is 2021-era. The post lands at a moment when "NoSQL for velocity" was still a live industry conversation. Some of its urgency has dissipated as document-store adoption matured and RDBMS tooling caught up (Vitess, gh-ost + managed platforms, Atlas / Skeema declarative tooling). The thesis still holds at the philosophical altitude.
  • Noach-as-gh-ost-author not disclosed in post. The gh-ost reference is load-bearing for the reader who knows Noach is gh-ost's creator (it frames the essay as a practitioner's reflection on why the tool he built was necessary but not sufficient), but the post doesn't make this connection — external knowledge required.
  • Pre-PlanetScale-product-depth. Post predates the 2022 revert mechanism (Guevara + Noach 2022-10), the 2024 instant-deploy fast path (Noach 2024-09-04), and the 2024 gated multi-change deployment mechanism. The prescription in the closing paragraph is aspirational in 2021; it became concrete product surface over the following three years.
  • No competitor engagement. CockroachDB's online schema change (Rae Marks, Peter Mattis 2017), Spanner's schema-version-vector approach, and the Liquibase / Flyway tradition are all unaddressed. The claim that "relational databases" collectively fail at operational schema change flattens meaningful vendor-by-vendor variation.
  • Prescription without mechanism. The closing paragraph names "developer ownership" and "joy" as goals without specifying what product surface delivers them. The 2022 paradigm essay does the specification work; this post is the problem statement alone.

Source

Last updated · 470 distilled / 1,213 read