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:
-
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.
-
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).
-
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.
-
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¶
- concepts/schema-change-operational-friction — the obstacle. The friction is what makes continuous schema deployment expensive; the whole paradigm is a specification for removing it.
- concepts/operational-relational-schema-paradigm — the ten-tenet solution specification. Every tenet is necessary for continuous schema deployment to work safely.
- concepts/coupled-vs-decoupled-database-schema-app-deploy — the app-vs-schema deploy-ordering discipline that applies at continuous rate.
- concepts/developer-schema-workarounds — the four anti-patterns developers reach for when continuous schema deployment is aspirationally promised but operationally infeasible.
- patterns/branch-based-schema-change-workflow — the product-layer wrapper that instantiates continuous schema deployment as a git-like workflow.
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.
Related¶
- concepts/schema-change-operational-friction
- concepts/operational-relational-schema-paradigm
- concepts/deploy-request
- concepts/developer-schema-workarounds
- concepts/coupled-vs-decoupled-database-schema-app-deploy
- concepts/online-ddl
- patterns/developer-owned-schema-change
- patterns/branch-based-schema-change-workflow
- systems/planetscale
- systems/mysql
- companies/planetscale