Making 768 servers look like 1 (PlanetScale)
A PlanetScale engineering explainer on sharding a transactional SQL database so a large fleet presents to applications as a single logical database. It is the founding source for the distributed end of operational-databases and for the database-sharding concept.
The scale example
- 256 shards × 3 servers each (1 primary + 2 replicas) = 768 servers.
- ~4 TB per shard, ~1 PB total, millions of queries per second.
- Applications connect to one hostname (
mydb.pscale.com) and never see the fan-out.
Why shard (the three bottlenecks)
The article motivates sharding by what read replicas can’t fix — the argument now lives on database-sharding: the single-writer WAL caps write throughput; replicas duplicate rather than distribute data, so capacity doesn’t grow; and monolithic backups to object storage can take days. Sharding splits the data across many primaries to attack all three.
The mechanism
A proxy router — Vitess for MySQL, PlanetScale’s own Neki for Postgres — parses SQL,
holds topology metadata (typically JSON), routes each query to the right shard by a hash-based
shard key (e.g. hashing user.id), aggregates cross-shard results, and pools connections. A
network load balancer in front presents the single connection endpoint. PlanetScale maintains
Vitess and built Neki, and recommends sharding “beyond a few terabytes of data.”
Tier & why it matters
T2 — a vendor engineering blog (PlanetScale sells the managed product), so it’s authoritative on its own architecture but has a product to promote; the mechanics (WAL bottleneck, hash routing, proxy aggregation) are standard and independently corroborable. It’s the counterpole to turso: where Turso collapses the OLTP database into a single process, this scales one across a sharded fleet while keeping the same one-database interface.
Related
planetscale · database-sharding · operational-databases · online-transaction-processing · turso · synthesis