Vitess
The MySQL sharding system planetscale maintains, and the piece that makes 768 servers answer to one hostname. Paged now that this wiki has read its documentation rather than only heard it named (vitess-query-serving-docs, v23.0).
The parts this wiki has evidence for
VTGate — the proxy applications actually connect to. It "routes traffic to the correct VTTablet servers and returns consolidated results back to the client," speaks the MySQL wire protocol so "your applications can connect to VTGate as if it is a MySQL Server," and picks destinations by weighing the sharding scheme, latency requirements and instance availability. It is also where cross-shard merging happens.
VTTablet — the per-MySQL-instance agent that VTGate routes work to, and the layer where Vitess parses queries a second time.
VSchema and vindexes — the sharding metadata. A vindex maps a column value to a shard, and a query's plan depends on the VSchema as much as on the SQL. A routing operator that can't name a vindex scatters.
Keyspaces — sharded or unsharded; an unsharded keyspace maps to a single MySQL database. Shards
are assigned by key ranges over binary values, with 0x80 as the midpoint, which allows uneven
splits.
VEXPLAIN — the plan/trace tool, from Vitess 16. Five modes; TRACE reports ShardsQueried per
operator and KEYS proposes sharding-key candidates from a statement's shape.
Where it sits
The proxy-router half of this spoke's embedded↔distributed axis: turso collapses the database into the process, Vitess explodes it across a fleet and spends its effort making the fleet look like one server. Its design commitment — push work down to MySQL, merge only what can't be pushed — is why it can keep the MySQL interface honest without becoming a distributed query engine.
Sibling: neki, planetscale's Postgres equivalent — described here since 2026-09-19 and no
longer just a name. The comparison is closer than PlanetScale's own framing of it. Router↔VTGate and
Sidecar↔VTTablet are the same split, the workflow names (MoveTables, Reshard, OnlineDDL) are Vitess's
unchanged, and harshit-gangal wrote both the Neki architecture post and a top-five share of this
project's commits. What Neki could not inherit is everything Postgres forces: OID reconciliation
through a cluster-wide authoritative shard, pg_rewind on the failover path, logical-replication
decoding as the data-movement primitive, and session advisory locks as a third connection-pool tier.
Topology from Vitess, mechanisms from Postgres.
The one design divergence worth naming: this page credits Vitess with not becoming a distributed query engine, pushing work down to MySQL and merging only what it must. Neki's Router picks between nested-loop, hash and merge joins on cost estimates for cross-shard work. Same instinct, one step further.
Version caveat: everything above is v23.0 documentation read on 2026-08-03; operator names, VEXPLAIN modes and defaults move between releases.
Related
database-sharding · cross-shard-queries · vitess-query-serving-docs · planetscale · planetscale-768-servers · neki · the-architecture-of-neki · turso · synthesis