Skip to content

PLANETSCALE 2024-09-04 Tier 3

Read original ↗

PlanetScale — Instant deploy requests

Summary

Shlomi Noach (PlanetScale, originally 2024-09-04, re-fetched 2026-04-21) announces instant deployments on eligible PlanetScale deploy requests: schema changes whose every statement qualifies for MySQL's native ALGORITHM=INSTANT DDL finish in seconds rather than the hours an Online DDL shadow-table migration would take on a large table. Instant is opt-in per deploy request — PlanetScale pre-evaluates eligibility and presents the user with an explicit choice, defaulting to Online DDL as "the default and safest schema change strategy." Canonical three-part eligibility rule + canonical two-caveat trade-off framing.

Key takeaways

  • Instant deployment exists as a fast-path parallel to Online DDL, not a replacement. Online DDL remains the default because it is safer (revertible, no lock spike); instant is the performance opt-in when the change shape permits it. "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: this post)

  • Three-part eligibility rule (canonicalised as concepts/instant-deploy-eligibility): a deploy request qualifies iff every statement is one of — (a) one or more ALTER TABLE statements each qualifying for MySQL ALGORITHM=INSTANT (canonicalised as concepts/instant-ddl-mysql); (b) any number of CREATE TABLE or DROP TABLE statements (trivially instant — no data migration); (c) any number of CREATE / MODIFY / DROP VIEW statements (metadata-only). A deploy request with even one non-qualifying statement falls back to Online DDL. (Source: this post)

  • Performance delta is large: Noach's framing contrasts "hours to deploy a schema change to a large tables" (Online DDL) against "just a few seconds" (instant) — a ~3–4 orders of magnitude wall-clock reduction on large-table schema changes eligible for INSTANT. (Source: this post)

  • Pre-evaluation is automatic: "PlanetScale pre-evaluates whether a deployment is eligible for instant deployment and presents the user with a choice." The eligibility check runs at deploy-request submission time, before any DDL executes. Canonicalised as patterns/instant-deploy-opt-in. (Source: this post)

  • Caveat 1 — non-revertible: "They are not [revertible]." Canonical contrast with Online DDL: the 30-minute revert window via inverse replication depends on the pre-staged inverse-replication substrate that shadow-table migrations produce as a by-product. Instant deployments skip the shadow-table build entirely, so there is no inverse replication to play back. Canonicalised as concepts/non-revertible-schema-change. (Source: this post)

  • Caveat 2 — transient multi-second table lock: "Under some workloads, users may experience a multi-second (or more) lock on the migrated table." MySQL's INSTANT algorithm still takes a metadata / data- dictionary lock briefly during the change; under write- heavy workloads this can block in-flight DML long enough for customers to notice. The lock duration is workload- dependent and not quantified in the post. (Source: this post)

  • Applies to MySQL only. The post is scoped to PlanetScale's MySQL product; the analogous Postgres story (Postgres has its own ADD COLUMN fast-path) is out of scope. (Source: this post)

Architectural substance

The fast-path / safe-path composition

PlanetScale's deploy-request architecture now has two execution paths based on eligibility:

Instant Online DDL (default)
Wall-clock on large table Seconds Hours
Mechanism Native MySQL ALGORITHM=INSTANT Shadow table build + cut-over
Revertible? No Yes — 30-minute inverse-replication window
Lock impact Possible multi-second table lock No app-visible lock (vtgate query buffering)
Availability Only when every statement qualifies Always
Decision gate Pre-evaluation + operator opt-in Default

The composition rule preserves safety as the default while giving performance-conscious operators an explicit fast-path when the change shape permits it. The pre-evaluation step is load-bearing — it removes the cognitive load of knowing which changes qualify from the operator and surfaces the choice only when the fast- path is actually available.

Why some changes qualify for INSTANT and some don't

The post links out to PlanetScale's earlier State of Online Schema Migrations in MySQL piece for the full INSTANT taxonomy. Noach's one-line summary: "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." The full eligibility matrix is MySQL-version-dependent (8.0 introduced INSTANT, 8.0.29 expanded it significantly). The general shape: metadata-only changes and a subset of data- dictionary-only changes are instant; anything requiring a full table rewrite (row-format change, many composite index adds, certain column-type changes) is not.

The INSTANT algorithm's mechanics — store new column metadata in the data dictionary, synthesise values from the stored default at read time for old rows — are outside this post's scope. The canonical framing here is product-level: "which deploy requests can take the fast path?", not "how does INSTANT work inside InnoDB?".

Why non-revertibility is structural, not a limitation

The 30-minute revert window isn't a separate feature layered on top of deploy requests — it's an emergent property of the shadow-table architecture. Online DDL builds a shadow table via VReplication; at cut-over the forward stream is re-primed in the inverse direction (new → old) and kept running; revert is the same shadow-table cut-over played backwards. No shadow table, no inverse stream, no revert.

Instant deployments bypass the shadow-table build entirely — there's nothing to re-prime in the inverse direction. The only revert path for an instant deployment is a compensating DDL (e.g. DROP COLUMN to undo an ADD COLUMN), which itself may or may not qualify for INSTANT and which doesn't restore data written after the forward deploy (the forward-add column would now contain values from post-deploy writes that the compensating drop discards). This is the same data-loss asymmetry discussed in sources/2026-04-21-planetscale-behind-the-scenes-how-schema-reverts-work for the non-INSTANT revert-by-restore path.

Why the lock caveat matters

MySQL INSTANT DDL still acquires a metadata lock on the target table for the duration of the data-dictionary update. Under low write pressure this is microseconds. Under heavy write concurrency, the lock can be held seconds or more waiting for in-flight transactions to commit or roll back — and during that window, any new DML blocks. The post's "multi-second (or more)" phrasing is deliberately imprecise: duration depends on workload, server-side configuration, and table-specific contention. PlanetScale surfaces this as a caveat rather than a blocker because it's load-bearing information for operators but not generally deterministic enough to gate the fast-path on automatically.

This is a different lock phenomenon from the cut-over window in Online DDL. Online DDL's cut-over is also brief (sub-second typical) and mitigated by vtgate query buffering. Instant's lock is on the forward metadata change itself, not on a table-swap, and is not query-buffered by vtgate because the lock is at the MySQL tablet level, below where vtgate routing intervenes.

Systems / concepts / patterns

Systems named: systems/planetscale, systems/vitess (by implication — deploy requests execute through Vitess online-migration workflow), systems/mysql (substrate providing ALGORITHM=INSTANT).

Concepts canonicalised:

  • concepts/instant-ddl-mysql — new page. First canonical wiki treatment of MySQL's ALGORITHM=INSTANT as an engine-level primitive (previously referenced in passing in concepts/online-ddl and the 2026-04-21 Vitess 21 release notes without a dedicated page).
  • concepts/instant-deploy-eligibility — new page. Canonicalises the three-part composition rule (all- ALTER-qualify + optional CREATE/DROP table + optional CREATE/MODIFY/DROP view) as the gate determining fast-path availability per deploy request.
  • concepts/non-revertible-schema-change — new page. Canonicalises the distinction between shadow-table-based schema changes (revertible via inverse replication) and metadata-only fast-path changes (non-revertible because no inverse-replication substrate exists).
  • concepts/online-ddl — extended. New Seen-in entry framing instant deployments as a fast-path parallel to Online DDL; the two coexist rather than substitute.
  • concepts/deploy-request — extended. Canonical pre-evaluation step added to the deploy-request lifecycle: at submission time, the system decides whether the fast-path is available and offers an opt-in to the user.

Patterns canonicalised:

  • patterns/instant-deploy-opt-in — new page. The composition shape: automatic pre-evaluation of fast- path eligibility + operator opt-in when eligible + safe-slow default when not. Generalises beyond schema changes — applies to any operation with a conditional fast-path whose safety properties differ from the default.
  • patterns/shadow-table-online-schema-change — extended. New Seen-in entry noting the instant- deployment alternative for changes that don't need shadow-table mechanics.
  • patterns/instant-schema-revert-via-inverse-replication — extended. New Seen-in entry noting the structural coupling of revertibility to shadow-table architecture and the explicit non-revertibility of instant deployments.

Operational numbers

Noach provides one qualitative scaling datum:

  • Online DDL on a large table: hours.
  • Instant deployment: "just a few seconds."

No specific table sizes, row counts, or lock-duration histograms are disclosed. The "multi-second" lock caveat is qualitative.

Caveats

  • Short post (~1,900 characters of body). The post is a product-announcement-plus-architecture-note, not a deep mechanism disclosure. It defers the INSTANT taxonomy to the linked State of Online Schema Migrations piece. Internal mechanics of how PlanetScale performs the eligibility evaluation (INFORMATION_SCHEMA query? planner hint? schemadiff library analysis? — the 2026-04-21 Vitess 21 release notes mention "more INSTANT DDL scenario analysis beyond the documented limitations" going into schemadiff, which is suggestive) are not disclosed.
  • Lock duration workload-dependent and unquantified. "Multi-second (or more)" is deliberately vague. No guidance on when the lock is likely to be noticeable vs negligible.
  • Revert trade-off asymmetric. Caveat 1 says instant deployments "are not [revertible]" but doesn't walk through what revert options do exist (compensating DDL with data-loss asymmetry — the same shape as restore-from-backup on a non-INSTANT deploy after the 30-minute window expires).
  • No adoption metrics. No disclosure of customer uptake, opt-in rate, or post-hoc revert-regret incident rate.
  • MySQL-only scope. PlanetScale for Postgres (GA'd 2025) is out of scope.
  • Re-surface date. Original publication 2024-09-04, RSS re-fetched 2026-04-21. The product surface may have evolved — the 2026-04-21 Vitess 21 release notes mention "more INSTANT DDL scenario analysis" which suggests the eligibility envelope has widened since this post.
  • Tutorial-style voice at a product-architecture altitude. Not a deep-dive retrospective.

Source

Last updated · 378 distilled / 1,213 read