SYSTEM Cited by 1 source

PlanetScale MySQL server fork¶

What it is¶

PlanetScale's MySQL server fork is PlanetScale's public downstream of upstream MySQL server, hosted at github.com/planetscale/mysql-server. The fork carries PlanetScale-specific patches that extend MySQL's server + InnoDB behaviour in ways that are necessary for Vitess-native Online DDL, foreign-key-constraint support, and other PlanetScale-platform features — but that upstream MySQL is unlikely to take either for scope or conservatism reasons.

Relationship to upstream MySQL¶

The fork stays current with upstream releases and adds additive patches on top. It is not a hard-fork competing with MySQL (no feature divergence of the query engine, storage format, or protocol) — it ships as a vanilla MySQL that understands a handful of extra server variables and table-level markers.

PlanetScale's managed service runs this fork across its fleet. Self-hosted Vitess users running on upstream MySQL get everything except the features gated on the fork's patches.

Notable patches disclosed on the wiki¶

`rename_table_preserve_foreign_key`¶

Server variable introduced in commit bb777e3e. When set to 1, RENAME TABLE parent TO parent_old preserves each child table's FK definition pinned to the name parent rather than following the table's internal pointer to parent_old. See concepts/innodb-parent-table-rename-pinning for the mechanism and why it is necessary for shadow-table Online DDL on FK parents.

Internal operations tables¶

A table-level marker that exempts specific tables from FK validation + cascading — "as if we SET FOREIGN_KEY_CHECKS=0 for specific tables, even while the transaction otherwise applies foreign key logic to other tables." Used by Vitess to mark shadow tables during Online DDL so they don't interfere with the live parent-child FK graph. See concepts/innodb-internal-operations-table.

Design rationale for forking rather than upstreaming¶

From the source post, PlanetScale considered two paths for reconciling InnoDB's FK cascade behaviour with Vitess's binlog-dependent workflows:

Patch InnoDB to log cascades in the binlog — would require changes to InnoDB's codebase, which is "very much detached from the MySQL codebase. There are parallel constructs, parallel entities in MySQL and in InnoDB, which are completely different and do not translate well to one another." High risk, high review surface in upstream.
Implement FK logic in Vitess instead — low risk to Vitess (maintainers have clarity of scope), generalises to cross-shard in the future.

They chose path 2 for FK logic. But path 2 doesn't eliminate the need for some MySQL-side changes: the shadow-table Online DDL flow needs server-side cooperation to coexist with FK-carrying tables. Hence the fork, with minimally-invasive patches targeting only the shadow-table-+-FK interaction surface. The patches are small and surgical — introducing a server variable (default 0, upstream-compatible behaviour) and a table-level marker, not rewriting any core FK logic.

Composition with Vitess cherry-pick bot¶

The wiki-canonical Vitess cherry-pick bot is a sibling tool managing automated cherry-picks between OSS and private forks of Vitess itself. The MySQL server fork is an analogous artefact for the MySQL side of the stack — PlanetScale runs some number of per-release synchronisation flows to keep the fork up with upstream. The source post doesn't disclose whether a similar bot exists for mysql-server specifically; the Vitess cherry-pick bot's design suggests the pattern would generalise (see concepts/fork-upstream-sync).

Seen in¶

sources/2026-04-21-planetscale-the-challenges-of-supporting-foreign-key-constraints — canonical wiki home. First explicit wiki disclosure of github.com/planetscale/mysql-server as a first-class PlanetScale asset (the Vitess post corpus references the Vitess private/OSS forks, but the MySQL-server fork is distinct). Noach + Gupta name the rename_table_preserve_foreign_key patch inline with a commit URL, and describe the internal-operations-tables primitive without naming a commit (implementation detail omitted). The fork's existence is the mechanism by which Vitess's FK support is made compatible with shadow-table Online DDL.