PATTERN Cited by 1 source

Instant-deploy opt-in¶

Problem¶

A system has two execution paths for the same operation that differ materially in trade-offs:

A fast path that is much faster but has operator-visible caveats (different failure modes, reduced rollback options, different resource profile).
A safe path that is slower but has well-understood properties the operator is already calibrated on.

Not every instance of the operation is compatible with the fast path — eligibility depends on structural properties of the specific operation, not on operator intent. How should the system surface the choice?

Three anti-patterns:

Always take the fast path when possible. Operators get surprised by new caveats they didn't opt into. When the caveats bite (e.g. an unexpected revert scenario), the surprise attribution lands on the platform.
Never take the fast path. The performance is left on the table. The fast path exists for a reason.
Require the operator to know which operations qualify. Eligibility rules are often intricate (e.g. MySQL ALGORITHM=INSTANT has a non-trivial MySQL-version-dependent envelope). Offloading this cognitive load to every operator is a recipe for mistakes — operators will either never opt in (losing the benefit) or opt in wrong (taking the caveats unintentionally).

Solution¶

Pre-evaluate eligibility automatically, surface the choice only when eligible, and default to the safe path. Three structural moves:

Automatic pre-evaluation — at operation- submission time, the system analyses the operation's structure against the fast-path eligibility rule. The operator is not required to know the rule.
Conditional opt-in UI — when eligible, present the operator with an explicit choice between fast and safe paths, including the caveats of the fast path in plain language. When not eligible, just execute the safe path without offering the choice.
Safe default — the default state of the opt-in control is the safe path. The operator must take an explicit action to select the fast path. This makes the caveats an acknowledged trade-off, not a surprise.

Canonical shape (PlanetScale, Noach 2024):

"PlanetScale pre-evaluates whether a deployment is eligible for instant deployment and presents the user with a choice. … PlanetScale continues to run Online DDL as the default strategy, and users are asked to make an explicit choice when opting for instant deployments." (Source: sources/2026-04-21-planetscale-instant-deploy-requests)

Canonical instance¶

PlanetScale instant deploy requests for MySQL schema changes. The two paths:

Property	Fast path (instant)	Safe path (Online DDL)
Wall-clock on large table	Seconds	Hours
Mechanism	MySQL `ALGORITHM=INSTANT`	Shadow-table build + cut-over
Revertible?	No	Yes — 30-min inverse-replication window
Lock impact	Possible multi-second metadata lock	No app-visible lock (vtgate buffering)
Default?	Opt-in	Default

Eligibility is canonicalised in concepts/instant-deploy-eligibility: the deploy request qualifies iff every statement is an INSTANT-qualifying ALTER, a CREATE/DROP TABLE, or a CREATE/ALTER/DROP VIEW.

The UI shape:

Deploy-request is submitted.
PlanetScale pre-evaluates eligibility at submission time (using Vitess schemadiff analysis, per the Vitess 21 release notes).
If eligible, the deploy-request UI shows an "Instantly deployable request" affordance alongside the usual Online DDL flow, presenting the operator with the option to opt in.
If not eligible, the UI shows the standard Online DDL flow — no choice, no friction.
Either way, the default is Online DDL. The operator must click the instant-deploy opt-in to choose the fast path.

Why the default is safe¶

Noach's rationale is explicit about the safety-vs- performance trade-off:

"These caveats do come with some caveats: They are not [revertible]. Under some workloads, users may experience a multi-second (or more) lock on the migrated table. For these reasons, PlanetScale continues to run Online DDL as the default strategy." (Source: sources/2026-04-21-planetscale-instant-deploy-requests)

The structural argument:

Online DDL's properties are well-understood — PlanetScale's operators have years of experience with the 30-minute revert window, the sub-second cut-over, the shadow-table semantics.
Instant's caveats are operator-dependent — the lock duration depends on workload; the non-revertibility consequences depend on whether the change is compensable. An operator who knows their workload can decide; an operator who doesn't should default to safe.
Default-safe + explicit-opt-in assigns responsibility — when the operator opts in, they are acknowledging the caveats. When they don't opt in, the safe path runs with its known properties. Neither outcome involves surprise.

Generalisation beyond schema changes¶

The pattern applies to any operation with a conditional fast-path whose safety properties differ from the default. Canonical shape:

Detect eligibility: automatic analysis of the specific operation's structure.
Surface conditionally: show the opt-in only when eligible.
Default safe: safe path is the default; fast path requires explicit opt-in.
Attach caveats to opt-in: the caveats of the fast path are surfaced at the opt-in moment, not buried in documentation.

Other wiki instances with similar shape:

Gated deployment's Auto-apply checkbox — PlanetScale's auto-apply of a ready-to-cut-over deploy is default-on (so deploys finish automatically) but can be opt-out'd for operator-scheduled cut-over. Same structural shape with an inverted default — here the default is the fast path (auto-apply) and the opt-in is the slow path (manual cut-over), because the trade-off is reversed.
Consistent Lookup Vindex — Vitess's ordered commit is the default for cross-shard writes; the explicit- opt-in is the stricter atomic distributed transactions with 2PC-like guarantees. Same shape, trade-off is correctness-vs-availability.

When the pattern is the wrong choice¶

Both paths have the same safety properties — the opt-in is then just friction. Pick the faster one as the default.
Eligibility is too unstable to pre-evaluate reliably — if eligibility depends on runtime state that changes between pre-evaluation and execution, the opt-in becomes a false promise. Schema-change eligibility is stable (depends on DDL shape); some runtime optimisations are not.
The operator population is too inexperienced to reason about the caveats — in some deployments the opt-in just becomes friction everyone clicks through without thinking. Better to make the caveats a hard failure of the fast-path attempt (fail closed) than to offer an opt-in that's routinely taken without understanding.

Composes with¶

concepts/instant-deploy-eligibility — the eligibility rule the pre-evaluation step implements.
concepts/non-revertible-schema-change — the specific caveat the operator is opting into when choosing the fast path.
patterns/shadow-table-online-schema-change — the safe-path mechanism the default runs.

Seen in¶

sources/2026-04-21-planetscale-instant-deploy-requests — canonical disclosure. Shlomi Noach (PlanetScale, 2024-09-04) canonicalises the opt-in shape with the "Instantly deployable request" UI affordance explicitly: "PlanetScale pre-evaluates whether a deployment is eligible for instant deployment and presents the user with a choice." The default-safe posture is stated explicitly with the caveats as rationale. The pattern generalises beyond schema changes to any conditional-fast-path operation with operator-visible trade-offs.