CONCEPT Cited by 1 source

MySQL ALGORITHM=INPLACE¶

Definition¶

ALGORITHM=INPLACE is a MySQL ALTER TABLE execution strategy where InnoDB rebuilds the table in place inside the MySQL server process (without an external shadow-table tool) while allowing concurrent DML (SELECT, INSERT, UPDATE, DELETE) on the table being altered. Introduced in MySQL 5.6 as the first native "online" DDL option, INPLACE predates the later ALGORITHM=INSTANT fast-path by several years and covers a different (broader but more expensive) slice of eligible change shapes — typically those that require a full table rebuild but can still permit concurrent writes via row-versioning.

Why it matters¶

INPLACE was MySQL's "first take on non-blocking schema changes" (Noach, 2024). Where INSTANT is metadata-only, INPLACE actually rebuilds the table — so it pays real CPU, disk, and I/O cost — but remains non-blocking on the origin server. A large class of changes that INSTANT cannot satisfy (most index builds, primary-key changes on some shapes, charset migrations on some shapes) are INPLACE-eligible. See the MySQL 8.0 Online DDL Operations documentation for the exhaustive eligibility matrix.

Four operational caveats¶

Noach (2024) enumerates why INPLACE is not the default recommendation on PlanetScale even when eligible:

Non-blocking only on the query-submission server (normally the primary). DML proceeds on the primary during the operation; other DDL blocks and that's expected.
Resource-greedy. Verbatim: "the MySQL server will use as much CPU and disk I/O to complete the change as it can. This can and will impact performance on busy servers." The operation has no built-in throttling against production-workload contention.
Extra-disk-space requirement. "Up to as much disk space as the original table" for the rebuild substrate. On TB-class tables, this is a real pre-flight capacity check.
Uninterruptible. "The only way to abort is to kill the query aggressively. This then leads to a further massive cleanup operation, consuming more disk I/O." Compare with shadow-table tools where cancellation before cut-over is a zero-cost drop of the shadow table.

The replica-lag deal-breaker¶

The single load-bearing property that makes INPLACE unusable in most production topologies:

"On replica servers, the operation is NOT non-blocking. Meaning if the ALTER TABLE took 3 hours on the primary server, then from the moment it completes you can expect replication to stall while applying that same change for the next 3 hours or so, creating a massive 3 hour lag." (Source: sources/2026-04-21-planetscale-the-state-of-online-schema-migrations-in-mysql)

The operation replicates through the binlog as a single ALTER TABLE statement; replicas run it serially inside their SQL apply thread, blocking all replication during the rebuild. A 3-hour primary rebuild becomes 3-hour write-after-read inconsistency on every replica — catastrophic for any workload that depends on replicas for reads or failover.

The workaround and why it's worse¶

Noach documents the classical workaround:

"One way around it is to run the ALTER TABLE on the primary with SQL_LOG_BIN=0 so that it does not replicate. Then, run it similarly individually on each replica."

Why this doesn't save the approach:

Consistency risk. If the operator misses a replica, or a replica is bootstrapped from a backup taken before the change, that server permanently diverges. Manual tracking is required.
O(n) operator time. The change runs once per server; parallelism helps but doesn't eliminate the coupling between operator attention and cluster size.
Future-replica provisioning risk. New replicas bootstrapped from backup may or may not need the change — operator needs per-backup-generation knowledge.

Noach's conclusion: "For these reasons we find that INPLACE is not a good option for non-blocking changes."

Relationship to other mechanisms¶

Axis	`INSTANT`	`INPLACE`	Shadow-table tools
Change-shape coverage	Narrow (metadata)	Medium	Broad (near-universal)
Wall-clock time	Seconds	Hours on large tables	Hours on large tables
Disk overhead	Zero	~= table size	~= table size
CPU/I/O	Zero	High (uncapped)	Throttleable
Replica behaviour	Instant on replicas	Serial replay, massive lag	Throttleable on replicas
Interruptible	N/A (instant)	No (aggressive kill only)	Yes (drop shadow)
Revertibility	Non-revertible at metadata level	Compensating-DDL only	Inverse replication

Seen in¶

sources/2026-04-21-planetscale-the-state-of-online-schema-migrations-in-mysql — Shlomi Noach (PlanetScale, 2024-07-23). Canonical wiki disclosure of INPLACE and its four-caveat profile + the replica-lag deal-breaker. The structural framing: INPLACE is what MySQL shipped before INSTANT, still covers the broadest native eligibility matrix, but its replica-side behaviour makes it unusable in primary-replica topologies without manual per-replica coordination. The SQL_LOG_BIN=0-then-replay-per-replica workaround is technically correct but operationally worse than switching to a shadow-table tool. "For these reasons we find that INPLACE is not a good option for non-blocking changes."