CONCEPT Cited by 1 source

Instant-deploy eligibility¶

Definition¶

Instant-deploy eligibility is the three-part composition rule PlanetScale applies at deploy-request submission time to decide whether a schema change can be executed via MySQL's native ALGORITHM=INSTANT fast-path (seconds on a large table) or must fall back to the shadow-table-based Online DDL path (hours on a large table). A deploy request qualifies if and only if every statement in it falls into one of three classes:

One or more ALTER TABLE statements each qualifying for MySQL ALGORITHM=INSTANT individually.
Plus optionally, any number of CREATE TABLE or DROP TABLE statements — trivially instant because there is no existing data to migrate.
Plus optionally, any number of CREATE VIEW / ALTER VIEW / DROP VIEW statements — views are metadata-only; no data rewrite is ever needed.

Verbatim (Noach, 2024):

"To qualify for instant deployment, a deploy request must consist of changes all of which can be fulfilled instantly: One or more ALTER TABLE statement that qualifies for INSTANT DDL in MySQL. Plus, optionally, creating or dropping any number of tables. Plus, optionally, creating, modifying, or dropping any number of views." (Source: sources/2026-04-21-planetscale-instant-deploy-requests)

The all-or-nothing property¶

The rule is all-or-nothing at the deploy-request level. A deploy request bundling ADD COLUMN (instant- eligible) with ADD INDEX (not instant-eligible) does not partially-qualify — the whole request falls back to Online DDL. This is a consequence of atomicity: the deploy request is the unit of cut-over, and mixing instant and non-instant paths within one unit would compose poorly with the gated-deployment cross-change cut-over coordination.

The operational implication: break large multi-change deploy requests into single-class deploy requests if you want the instant fast-path to apply to the portion that qualifies. The schema-change queue will serialise them in order.

Why the three classes¶

Each class has a distinct reason for being instant:

ALTER TABLE ... ALGORITHM=INSTANT-qualifying: the change is metadata-only at the MySQL engine level. MySQL's data dictionary can absorb the change without touching any row data. See concepts/instant-ddl-mysql for the full eligible-change taxonomy.
CREATE TABLE: by definition there is no existing data. Creating an empty table is a metadata-only operation.
DROP TABLE: MySQL deallocates the tablespace as a background operation; the table disappears from the schema immediately. The post's framing treats this as fast-path-eligible, though the underlying tablespace reclamation may take longer (asynchronous).
CREATE / ALTER / DROP VIEW: views are SQL definitions stored in the data dictionary. They have no on-disk data of their own.

Pre-evaluation mechanism¶

The check runs at deploy-request submission time — before any DDL executes. The post's framing:

"PlanetScale pre-evaluates whether a deployment is eligible for instant deployment and presents the user with a choice." (Source: sources/2026-04-21-planetscale-instant-deploy-requests)

Internal mechanism is not fully disclosed, but the 2026-04-21 Vitess 21 release notes mention "more INSTANT DDL scenario analysis beyond the documented limitations" moving into Vitess's schemadiff library — suggesting the evaluator is a schemadiff-based semantic analysis rather than a simple pattern-match on the DDL string. schemadiff can reason about the pre- and post-schema in structural terms and detect changes that are semantically metadata- only even when the DDL syntax might suggest otherwise. (Source: sources/2026-04-21-planetscale-announcing-vitess-21)

Operator opt-in after eligibility¶

Eligibility is necessary but not sufficient for instant deployment — the operator must still explicitly opt in. See patterns/instant-deploy-opt-in for the full opt-in shape. PlanetScale's rationale:

"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)

The explicit opt-in exists because the two caveats on instant deployments — non-revertibility (see concepts/non-revertible-schema-change) and possible multi-second lock — are operator-visible trade-offs, not hidden details. Making the opt-in explicit ensures the operator knowingly accepts both.

Consequences¶

Revertibility is bound to the path. Online DDL gives you the 30-minute inverse-replication revert window as a structural consequence of the shadow-table build; instant deployment gives you no automatic revert. See concepts/non-revertible-schema-change.
Lock semantics differ. Online DDL's application- visible lock is sub-second (vtgate query buffering hides the cut-over moment). Instant's lock is at the MySQL tablet level, outside vtgate routing, and can be multi-second under write-heavy workloads.
Mixing paths in one request forces the slow path. Operators who want the fast path on part of a change set must split the deploy request.
Eligibility may expand over time. MySQL's INSTANT envelope has expanded from 8.0 to 8.0.29+, and Vitess's schemadiff analysis widens it further. A change that's not instant-eligible today may become eligible on a future MySQL or Vitess upgrade.

Seen in¶

sources/2026-04-21-planetscale-instant-deploy-requests — canonical product-altitude disclosure. Shlomi Noach (PlanetScale, 2024-09-04) canonicalises the three-part composition rule verbatim and positions eligibility as the gate determining fast-path availability per deploy request. The rule is structural: it depends only on the statement shapes in the request, not on runtime load or table size.