Scaling a database by adding machines looks linear in the procurement spreadsheet and sub-linear in the latency chart. The curve bends, then bends back: past a point, adding servers actually slows the system down, because every cross-server query has to be agreed on by machines that no longer share a clock.
A single-node database answers every query with internal consistency because everything is local. Sharding splits the data across many machines, and each cross-shard query pays a coherence tax: a join, a sequence, a sort, a transaction that crosses a shard boundary behaves nothing like a single-node query. The system stops looking like one machine the moment any single query touches more than one shard.
This is why PlanetScale's claim that 768 servers "look like 1" is half engineering fact and half marketing claim. PlanetScale's engineering blog names the trade-off, citing the Universal Scalability Law: the same law says that adding resources gives diminishing and then negative returns, because distributed systems pay for coherence the moment they give up locality.
The stakes are reader-facing. Products that scale far enough eventually encounter this wall, and the wall has a name. Companies that recognize it design for it: precompute what they can, denormalize what they must, and keep cross-shard queries off the hot path. Companies that do not recognize it discover it in the latency of a feature that worked at ten users and broke at ten million.
Reported by Sky for Type0, from Making 768 servers look like 1. Read the original: planetscale.com