CONCEPT Cited by 2 sources

Schema-change queue¶

Definition¶

A schema-change queue is a per-target serialisation primitive that orders concurrent schema-change submissions from multiple engineers and runs them in submission sequence, with a safety check on the combined post-deploy schema at each step.

Canonical verbatim disclosure (Coutermarsh, 2024 PlanetScale):

"When we have multiple team members making schema changes at the same time, PlanetScale will create a queue for each change. This allows each change to be deployed automatically in the order it was added to the queue. It has safety benefits as well, PlanetScale runs safety checks not only on each schema change, but on the resulting database schema with all changes combined. This protects against mistakes when multiple people are making changes at once."

(Source: sources/2026-04-21-planetscale-how-planetscale-makes-schema-changes.)

The problem it solves¶

Coupled-deploy teams hit a second-order failure mode as they scale: "larger teams deploying frequently get blocked by each others schema changes and suffer from higher coordination costs." The failure mode has two shapes:

Race conditions on concurrent DDL — two engineers submit overlapping changes in the same window; without serialisation, the outcome depends on interleaving order, which is non-deterministic.
Individually-safe changes that combined become unsafe — change A passes lint in isolation, change B passes lint in isolation, but the post-deploy schema with both applied violates an invariant (e.g. two unrelated migrations each add a column with the same name but different types).

The queue eliminates (1) by construction — it is the global order. It mitigates (2) by re-linting the combined post-queue schema at each step.

Two load-bearing properties¶

1. Serialisation in submission order¶

Submissions are FIFO-ordered. Each change waits until the previous change has completed before the queue admits it. The guarantee is single-writer per target at the schema layer, even when multiple PRs are open.

2. Combined-schema lint at each step¶

Each queue step runs two linters:

Per-change lint — the individual DDL statement.
Combined-schema lint — the schema as it will exist post-deploy with every queued change applied.

(2) is the non-obvious piece. It catches the class of bug where each engineer's diff looks safe locally but the collective effect produces an invalid schema.

Relationship to other coordination primitives¶

Compare to gated deployments:

Primitive	Scope	What it solves
Gated deployment	Within one deployment unit	Multiple changes + multi-shard readiness
Schema-change queue	Across deployment units over time	Multiple engineers submitting concurrently

They compose — a queue's entry may itself be a gated multi-change deployment.

Compare to multi-shard schema sync: that primitive solves the spatial concurrent-change problem (one change across N shards); the queue solves the temporal concurrent-change problem (N changes over time from N engineers).

Why this is harder than it looks¶

Naively: just serialise. But the queue has to handle:

Queue entries can depend on each other — engineer A adds table X, engineer B drops a column from X; B must wait for A.
Long-running migrations — an 8-hour ALTER at the head of the queue blocks everything behind it unless the queue can stage + gate.
Failure mid-queue — what happens to queued changes behind a failed one? Pause? Cancel all? Let them retry?
Combined-lint failure — if the combined-schema lint fails mid-queue, which change is at fault? Rejecting the newest is operator-unfriendly; rejecting the whole queue is worse.

Coutermarsh's post does not disclose how PlanetScale handles these corner cases; the queue is stated as an operational property rather than a mechanism.

Seen in¶

sources/2026-04-21-planetscale-non-blocking-schema-changes — Lucy Burns, PlanetScale, 2021-05-20. Canonical early public disclosure of the schema-change queue; introduces the serial-over-concurrent operational claim. Verbatim: "The deploy queue represents all of the deploy requests, or schema changes, for a given database that are awaiting deployment. PlanetScale deploys schema changes in the order in which they are received. (In our experience, deploying schema changes one at a time is generally more efficient than running them concurrently, with a few exceptions.)" The "generally more efficient" disclosure is the 2021 production-experience rationale for serialisation as a design choice, not merely a convenience. Burns also couples the queue with queue- admission conflict checking: conflicting deploy requests are rejected from the queue, not merely sequenced behind their conflictors.
sources/2026-04-21-planetscale-how-planetscale-makes-schema-changes — canonical disclosure at operator-facing altitude. "PlanetScale will create a queue for each change… deployed automatically in the order it was added to the queue… safety checks…on the resulting database schema with all changes combined." Framed as the automatic-coordinator that mitigates coupled-deploy's "larger teams getting blocked by each others schema changes" failure mode.