CONCEPT Cited by 2 sources

Gated schema deployment¶

Definition¶

Gated schema deployment is PlanetScale's coined term for the deployment-unit model where "all your changes are staged for however long it takes for all of them to be ready" and then completed together. The "gate" is the readiness check: the deployment does not advance to cut-over until every migration in the unit reports ready-to-complete.

Canonical verbatim framing:

"Gated deployments offer a change of concept, where all your changes are staged for however long it takes for all of them to be ready. In our example above, we can assume at around 24 hours for all changes to become ready. At that point, we complete the deployment, applying all the changes in production all at once."

(Source: sources/2026-04-21-planetscale-deploying-multiple-schema-changes-at-once)

The word "gated" carries two meanings simultaneously:

Coordination gate — the deploy controller holds every migration in staging until every migration is ready; the gate releases when the last migration catches up.
Cancellation gate — the deployment is cancellable at any moment up to the gate opening; until then, no changes are visible to the production application.

Relationship to near-atomic deployment¶

Gated deployment is the operator-facing mechanism that delivers near-atomic schema deployment. Near-atomic is the property (cut-over window in seconds, not hours); gated deployment is the deployment ceremony (stage everything → wait for readiness → release the gate → seal together).

The post uses the two terms almost interchangeably, with "near-atomic" emphasising the atomicity property from the application's view and "gated" emphasising the readiness- coordination mechanism from the operator's view.

Operator-facing properties¶

1. Cancel-anytime up to the gate¶

"Since gated deployments allow you to pick your preferred time to complete the changes, you can control the time of the 'event.' And, if there is a change of heart during the staging period or an incident that takes over priorities, the deployment may be canceled without impacting production."

See concepts/cancel-before-cutover for the formal property. This is the key operational advantage over traditional sequential-apply: traditional deploys become "half-complete and un-cancellable" partway through; gated deploys are fully cancellable until the gate opens.

2. Operator controls cut-over timing¶

Because the gate is a controller-driven event rather than an immediate consequence of running DDL, the operator gets to choose when to open the gate. The natural semantics is "open the gate as soon as all migrations report ready," but the post says "you can pick your preferred time" — implying the operator can hold the gate closed even after all migrations are ready, scheduling the cut- over for off-hours or a specific deploy window.

3. Single application-visible event¶

"With this approach, there is only one 'major event' to this deployment." The production application sees one cut-over event (approximately, per near-atomic caveats), not N events spread over hours. Incident response, alert correlation, and rollback windows all reason about one point in time.

4. Composes with the 30-minute revert window¶

After the gate opens and the deployment seals, PlanetScale stages tentative reverts for the 30-minute revert window. If the operator reverts, the reverse-order revert composes with gated deployment's single-event property to make the revert also a single event.

Contrast with traditional multi-DDL sequential apply¶

Dimension	Traditional sequential apply	Gated deployment
Running time for N migrations	N × individual time	max(individual times)
Partially-deployed window	Hours to days	Seconds
Cancel partway	Impossible (already applied)	Free (just abort the gate)
App-visible "deploy events"	N	1
Schema drift from intent	Gradual	Binary (before / after gate)
Rollback strategy	Author reverse DDL	Reverse-order revert (automatic)

Seen in¶

sources/2026-04-21-planetscale-gated-deployments-addressing-the-complexity-of-schema-deployments-at-scale — canonical product-launch disclosure. Shlomi Noach's 2022-09-06 post is the earliest wiki source naming "Gated Deployments" as a product feature, introduces the multi-shard dimension ("tracking the progress of a schema deployment across all shards and holding off the final switch to the new schema until all shards are ready") as one of two orthogonal axes under "multi- dimensional deployments" (the other being multiple- changes-per-deploy), and canonicalises the operator- scheduled cutover UI primitive via the Auto-apply checkbox + Apply-changes button. The 2022 launch post is the canonical "what gated deployment does"; the 2023 successor is the canonical "how the multi-change variant works."
sources/2026-04-21-planetscale-deploying-multiple-schema-changes-at-once — canonical wiki coinage of "gated deployment." Shlomi Noach introduces the term in the 8-hour / 24-hour / 24- hour worked example as the alternative to "24 hours until it's complete, during that time the database is in a semantically inconsistent state." The cancellation, operator-choice-of-timing, and single-event properties are all named in this post.