Skip to content

CONCEPT Cited by 2 sources

Continuous schema deployment

Definition

Continuous schema deployment is the contract where schema migrations are treated as a routine, high-frequency operation — shipped multiple times per day, per engineer, through the same pipeline that ships application code — rather than as quarterly scheduled maintenance events. It is the modern schema-change contract that relational databases were not originally built for.

Canonical source:

"Today, it's not uncommon for popular services to run multiple schema migrations per day." (Source: sources/2026-04-21-planetscale-the-promises-and-realities-of-the-relational-database-model)

The before / after contract

Before (maintenance-window era)

  • A few schema changes per year.
  • Deployed during scheduled maintenance windows.
  • Planned weeks or months in advance.
  • DBA-reviewed, owner-coordinated, downtime-tolerated.
  • Read/write performance is the database's design target; schema change is a human process wrapped around a DDL statement.

After (continuous-deployment era)

  • Multiple schema changes per day per product team.
  • Deployed continuously alongside application code.
  • Authored with the same velocity as any other code change.
  • Developer-owned end to end; DBA as enabler not gatekeeper.
  • Read/write performance and schema-change velocity are both design targets; the database must offer schema-change-as-API alongside query-as-API.

The contract inverted between roughly 2000 and 2020. Products-as-a-service replaced boxed software; CI/CD replaced monthly releases; microservices multiplied the number of schemas per company. The relational database's operational surface did not keep up.

Why continuous schema deployment matters

Once the contract is continuous:

  1. Schema change is in the data path. The before-era assumption ("schema change is a maintenance operation") no longer holds. Every property of the data path applies: latency budgets, availability SLOs, blast-radius containment, observability, revertibility. Every gap in the database's schema-change surface shows up as an incident.

  2. Coordination becomes a continuous concern, not a scheduled one. Two developers can try to ship overlapping migrations against the same table at any moment. There is no longer a "migration window" to serialise within — serialisation has to be continuous, which requires automation (concepts/schema-change-queue + concepts/pre-flight-schema-conflict-check).

  3. Revert becomes a continuous concern. A bad migration at 3pm shouldn't wait for the next maintenance window to undo. Revert has to be a product feature (concepts/schema-revert), not a human procedure.

  4. Operational observability becomes a continuous concern. Monitoring, progress reporting, ETA estimation (tenet 6 of the concepts/operational-relational-schema-paradigm) matter because changes are constantly in flight.

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 naming of the new contract. Verbatim: "Today, it's not uncommon for popular services to run multiple schema migrations per day." The post frames the relational database's failure to support this contract as the load-bearing cause of developer flight to NoSQL.

  • sources/2026-04-21-planetscale-the-operational-relational-schema-paradigm — Shlomi Noach, PlanetScale, 2022-05-09. Reprises the same contract with different framing verbatim: "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." The paradigm essay then enumerates the ten tenets the database must satisfy for the contract to be deliverable.

Last updated · 470 distilled / 1,213 read