Skip to content

CONCEPT Cited by 1 source

Developer schema workarounds

Definition

Developer schema workarounds are the four anti-patterns Shlomi Noach observed (PlanetScale, 2021) developers reach for when the operational friction of shipping a schema change in production exceeds their willingness to pay. The workarounds are ranked here by increasing distance from the relational-model ideal:

  1. Stall and batch — withhold individual schema changes, aggregate several into one deployment.
  2. JSON column overloading — push new fields into schemaless JSON columns to avoid a migration entirely.
  3. Code-level workaround — write suboptimal application code that avoids needing a schema change.
  4. Flee to NoSQL — abandon the relational model for a document store where shape changes are row-local.

Canonical source (verbatim):

"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." (Source: sources/2026-04-21-planetscale-the-promises-and-realities-of-the-relational-database-model)

Why this matters

The load-bearing claim is causal: developer flight to NoSQL is not evidence that the document model is structurally superior to the relational model. It is evidence that schema change in relational databases operationally sucks. Fix the operational friction and the NoSQL flight stops.

This framing inverts the 2010s industry conversation. The common story was "NoSQL wins on velocity because schemaless is better." Noach's reframe: "NoSQL wins on velocity because the relational stack made schema change expensive." One framing says the data model is the problem; the other says the deploy model is the problem. The reframe shifts the design target from "build a better data model" to "build a better deploy model for the existing data model."

Every PlanetScale product surface since 2021 is designed to undo each of the four workarounds:

  • Against stall-and-batch: deploy requests make individual migrations cheap to ship, so there's no incentive to batch. Branch-based workflow lets changes flow one-at-a-time through PR-style review.
  • Against JSON overloading: reducing migration cost makes "add a proper column" operationally indistinguishable from "add a key to the JSON" — so proper typing wins on merit. Canonicalised as concepts/json-column-as-schema-escape-hatch.
  • Against code-level workarounds: with fast migrations, there's no velocity advantage to avoiding schema change; the correct-shape query wins.
  • Against NoSQL flight: PlanetScale's entire positioning is "keep the relational model, get NoSQL-speed deploys" — targeting the population of developers whose reason for fleeing is operational, not structural.

The four workarounds in detail

(1) Stall-and-batch

The developer writes code that needs a new column, but delays shipping it until 2–3 other teammates also need schema changes. All are merged into a single Friday night deploy.

Costs: - Risk amplifies. A batched migration has the combined failure modes of every change in the batch. Canonicalised at concepts/coupled-vs-decoupled-database-schema-app-deploy. - Feature latency grows. The oldest change in the batch has been blocked waiting for peers. - Debugging is worse. A batched failure requires bisecting to identify which change broke production.

Noach's frame: this is velocity loss disguised as safety. The deploys feel safer because they're less frequent, but the per-migration risk is higher and cumulative release time is the same.

(2) JSON column overloading

The developer adds a metadata JSON column (or reuses an existing one) and stuffs new fields there instead of adding proper typed columns. No schema migration fires.

Costs: canonicalised as concepts/json-column-as-schema-escape-hatch — loss of type enforcement, loss of schema-level validation, loss of query-planner shape awareness, and the much bigger future cost when a JSON key is retroactively promoted to a proper column (now every row needs a one-time data migration, which is exactly what was being avoided).

This workaround is the most insidious of the four because it's easy, the code compiles, tests pass — and the cost only materialises months later when the JSON shape has diverged across rows and the query pattern is trying to filter on a key that isn't indexed.

(3) Code-level workaround

The developer avoids needing a new column by writing application code that does something clever and suboptimal — multiple queries where one would do; an in-memory pivot where a SQL aggregation would; a denormalised read-path where a normalised one would serve better.

Costs: this is technical debt by default. The code is slower, harder to reason about, and the schema shape is an implicit dependency rather than an explicit contract. Future engineers see the workaround shape and replicate it, assuming it's deliberate.

(4) Flee to NoSQL

The developer (or team, or company) picks a document store for their new service — MongoDB, DynamoDB, Cassandra, Firestore — because "migrations are painless there."

Costs: all the RDBMS wins (joins, transactions, SQL expressiveness, referential integrity, mature tooling, decades of operational learning) are traded for schemaless freedom the team often later regrets. The reframe Noach advances: if the schema-change operational friction were fixed, the flight would lose its primary motivation. This workaround is the loudest of the four because it shows up in architectural decisions and tech-stack choices; it's also the hardest to reverse.

Composition with other concepts

Seen in

  • sources/2026-04-21-planetscale-the-promises-and-realities-of-the-relational-database-model — Shlomi Noach, PlanetScale, 2021-07-13. Canonical source. Enumerates all four workarounds in a single verbatim paragraph positioned as the developer response to the operational tax the post has just spent several paragraphs documenting. The framing is descriptive-then-prescriptive: Noach names the four responses he sees in the field, then argues that fixing the friction (the PlanetScale product thesis) retires all four. First-class canonical NoSQL-flight-is-caused- by-operational-friction thesis.
Last updated · 470 distilled / 1,213 read