CONCEPT Cited by 2 sources

Cancel-before-cutover¶

Definition¶

Cancel-before-cutover is the property that a staged- but-not-yet-sealed multi-migration deployment can be cancelled at any moment up to the cut-over freeze point with zero visible production impact. No shadow tables have been swapped in; no production writes are affected; the schema visible to the application is identical to before the deployment started.

Canonical verbatim framing:

"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. The friction point, where a schema may only be partially deployed, is reduced from days or hours to seconds."

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

Why it matters¶

In traditional sequential-apply multi-DDL deployments, the cancellation story is bad:

If three 8-hour ALTER statements are running sequentially and the operator cancels at hour 10, the first migration is already complete and irreversible. The second migration is partially through its rewrite; the third has not started.
Reverting the first migration requires authoring and applying a new DDL (potentially another 8 hours).
The schema is in a hybrid state for the duration of the rollback — more hours of partially-deployed window.

Under gated deployment, cancellation at hour 10 of a 24-hour staging period means:

All three migrations are in staged-then- sealed state — shadow tables built, tailing the binlog, no cut-overs applied yet.
Cancellation tears down the shadow tables, stops binlog tailing, releases resources.
Production schema is exactly what it was at hour 0. No forward-progress has leaked into the visible state.

The "friction point" — the window during which a cancellation costs anything — collapses from hours-to-days down to the seconds-long cut-over window.

When it applies¶

Cancel-before-cutover applies to:

Entire deploy-request cancellation — the operator aborts the request before sealing.
Incident response escalation — another incident takes priority; the schema-change work is paused until the incident clears.
Discovered design flaw — operator notices a schema- design mistake mid-staging and wants to revise.
Resource-cost re-evaluation — operator decides the staging cost (storage for N shadow tables, binlog tail cost) is too expensive given current load.

It does not apply after the gate opens. The cut-over marks the transition from "cancellable" to "revertable." Post- cut-over, undoing changes requires the separate reverse-order revert mechanism inside the 30-minute revert window.

Contrast with traditional rollback¶

Dimension	Traditional multi-DDL	Cancel-before-cutover
Cancellation cost	Reverse-DDL + hours	Shadow teardown, ~seconds
Schema state after cancel	Hybrid (partially reverted)	Identical to pre-deploy
Production write impact	Revert DDL runs on live table	None
Revert timeline	Hours to days	Immediate
Operator skill required	DBA authoring reverse DDL	Abort button

Composition¶

Cancel-before-cutover composes with reverse-order revert to cover the full deployment lifecycle:

Before gate opens → cancel (no production impact).
Immediately after gate opens (within 30 minutes) → reverse-order revert (data-preserving revert via inverse replication).
After 30-minute window closes → traditional forward migration (author a new deploy-request that undoes the previous one's schema).

The two mechanisms together give the operator an escalating ladder of abort options, with lower-impact options available for longer periods.

Relationship to branching¶

Cancel-before-cutover also makes experimentation cheap at deploy-request granularity. An operator can submit a speculative deploy-request, let it stage for hours, inspect the schema impact (via schemadiff analysis, etc.), and cancel if the changes are not desired. The cost is the staging resources; there is no production risk. This is structurally different from a traditional DBA workflow where every ALTER carries the weight of irreversibility once started.

Seen in¶

sources/2026-04-21-planetscale-gated-deployments-addressing-the-complexity-of-schema-deployments-at-scale — earliest canonical wiki disclosure. Shlomi Noach's 2022 Gated Deployments launch post composes cancel- before-cutover with the near-atomic framing in one sentence: "While not strictly atomically, the deployment can be considered more atomic; up till the final stage, no change is reflected in production. In fact, the deployment may be canceled at any point up until its completion time." The 2022 post extends the property to the multi-shard case by implication — under multi-shard schema sync, cancel-before-cutover applies across the full shard fleet (no shard has started its cut-over before the gate opens), and cancelling the deployment tears down shadow tables on every shard.
sources/2026-04-21-planetscale-deploying-multiple-schema-changes-at-once — canonical wiki framing. Shlomi Noach presents the property as the primary operational advantage of gated deployment over traditional sequential apply: "The friction point, where a schema may only be partially deployed, is reduced from days or hours to seconds." The framing is explicitly about incident response — "an incident that takes over priorities" is the canonical use case driving the feature design.