CONCEPT Cited by 2 sources

MySQL INSTANT DDL¶

Definition¶

MySQL ALGORITHM=INSTANT is a ALTER TABLE execution strategy introduced in MySQL 8.0 (with significantly expanded coverage in 8.0.29) that applies a schema change by updating only the data dictionary — no table rewrite, no row touching, no shadow-table build. On a table with billions of rows, an eligible INSTANT change finishes in milliseconds to seconds where the same change under ALGORITHM=COPY or ALGORITHM=INPLACE would take hours or days.

ALTER TABLE users ADD COLUMN title VARCHAR(64), ALGORITHM=INSTANT;
-- Milliseconds: no existing rows are touched. MySQL stores
-- the new column's metadata in the data dictionary and
-- synthesises the default value for old rows at read time.

The speed comes from a structural observation: for a narrow class of changes, the existing on-disk row format is compatible with both the old and new schema — so the rows don't need to be rewritten. The change can be completed by updating metadata only.

The eligible change set¶

The INSTANT algorithm covers a limited, MySQL-version- dependent set of DDL shapes. Canonical examples (not exhaustive):

Adding a column (including with a default value) — 8.0 shipped this; 8.0.29 relaxed the constraint that INSTANT-added columns had to be last.
Dropping a column — 8.0.29+.
Changing a column's default value — default is metadata only, no row touched.
Renaming a column — metadata only.
Changing a column's visibility (VISIBLE / INVISIBLE) — metadata only. See also concepts/mysql-invisible-column.
Dropping a column's default value — metadata only.
Modifying enum / set definitions by appending values — storage format unchanged, metadata extended.
Changing index visibility (MySQL invisible indexes).
Adding or dropping a virtual generated column — the column doesn't physically exist in storage, so adding / dropping it is metadata only.

Changes requiring a full table rewrite do not qualify: adding most secondary indexes, changing a column's type in ways that affect storage width, changing the primary key, charset / collation changes on indexed columns, row- format changes, and similar.

Shlomi Noach frames the set succinctly: "there is a limited set of changes for which MySQL supports the INSTANT algorithm, such as adding a new column, changing a column's default value, and more." (Source: sources/2026-04-21-planetscale-instant-deploy-requests)

Mechanics sketch¶

INSTANT DDL works by exploiting MySQL 8.0's data- dictionary-centric design. The data dictionary stores per-column metadata (including a version identifier per column) separately from the on-disk row format. When MySQL INSTANT-adds a column:

New column metadata is written to the data dictionary with a row-version field marking the column's introduction point.
No existing rows are modified — they still have the old row layout without the new column physically present.
On read, MySQL compares the row's version to the column's introduction version. Rows older than the column don't have it; MySQL synthesises the default value from the data dictionary at read time.
Future writes produce rows that include the new column at its correct offset.

This lazy-materialisation strategy is why INSTANT is so fast — it converts a O(rows) operation into a O(1) operation. The trade-off is a small per-read cost to handle the version-mismatch case, amortised across the eligible-rows subset.

Trade-offs¶

Eligibility is narrow and MySQL-version-dependent. The change must fit into the metadata-only envelope. One non-qualifying statement in a multi-statement ALTER disqualifies the whole statement. This is the composition constraint at the heart of concepts/instant-deploy-eligibility.
Metadata lock can still bite. INSTANT doesn't rewrite rows, but it still acquires an exclusive metadata lock on the table during the data-dictionary update. Under heavy write pressure the lock can wait seconds for in-flight transactions to finish, blocking new DML during the wait. PlanetScale surfaces this as the second caveat on instant deployments: "Under some workloads, users may experience a multi-second (or more) lock on the migrated table." (Source: sources/2026-04-21-planetscale-instant-deploy-requests)
Per-table version-increment cap. Some INSTANT operations consume a slot in a per-table row-version counter (commonly limited to 64 INSTANT column additions before the table must be rebuilt). This caps how many INSTANT-adds a single table can accumulate over its lifetime without a compacting rewrite.
Not revertible via inverse replication when routed through a shadow-table-based platform. Because INSTANT skips the shadow-table build, there is no inverse-replication substrate to play back for a revert. Canonicalised as concepts/non-revertible-schema-change.

Vitess integration¶

Vitess's Online DDL workflow performs INSTANT-eligibility analysis through its schemadiff library and routes eligible changes through a fast path. The 2026-04-21 Vitess 21 release notes specifically mention "more INSTANT DDL scenario analysis beyond the documented limitations" moving into schemadiff — suggesting Vitess's eligibility envelope can cover edge cases that a naïve MySQL client would miss. (Source: sources/2026-04-21-planetscale-announcing-vitess-21)

PlanetScale builds on this Vitess capability to offer instant deploy requests as a product feature — the user-facing surface over the engine-level INSTANT algorithm. See concepts/instant-deploy-eligibility for the composition rule.

Seen in¶

sources/2026-04-21-planetscale-instant-deploy-requests — canonical product-altitude disclosure of ALGORITHM=INSTANT as the engine substrate under PlanetScale's instant deploy requests feature. Noach summarises the eligible change set qualitatively ("a limited set of changes for which MySQL supports the INSTANT algorithm, such as adding a new column, changing a column's default value, and more") and positions it against Online DDL as a fast-path-vs-safe-path dichotomy. The post does not walk through INSTANT's internal mechanics — it is a product announcement of the user-facing opt-in over the engine primitive.
sources/2026-04-21-planetscale-announcing-vitess-21 — release-notes altitude: Vitess 21 ships "more INSTANT DDL scenario analysis beyond the documented limitations" into the schemadiff library. Canonical wiki datum that Vitess's eligibility envelope can exceed MySQL's default analysis by applying stricter reasoning about which changes are semantically metadata-only.