How 768 servers can act like one database

A single database server eventually runs out of room. For apps serving millions of customers and handling millions of queries per second, the usual breaking points are CPU, I/O, and the fact that writes still funnel through one primary node.

In a new PlanetScale post, the company lays out why sharding remains the practical way to scale Postgres and MySQL beyond a few terabytes. The example starts small: 2 terabytes of data spread across four shards, each storing 500 gigabytes and serving about one-quarter of the traffic. At the high end, 1 petabyte of data can mean 256 shards, each with one primary and two replicas. That adds up to 768 servers.

Read replicas help, but only to a point. They can absorb more SELECT traffic and improve availability, yet they do not increase data capacity because each replica is still a full copy of the primary. Writes remain limited by the primary’s write-ahead log (WAL), and large backups of a monolithic database can take hours or even days.

How the proxy layer routes queries

PlanetScale argues that the key to making hundreds of servers look like one database is the proxy layer — more specifically, a router that sits between the app and the database nodes. In a non-sharded setup, tools like PgBouncer mainly handle connection pooling and query queuing. In a sharded system, the router also needs to understand where data lives and send each SQL query to the right place.

Recommended reading

Europe’s chip push won’t end US cloud reliance

That means the router must:

• know the sharding strategy
• map rows to the right shard on writes
• route simple reads to one shard
• split and aggregate multi-shard queries
• handle query parsing, planning, connection pooling, and buffering

The post uses a common example: hashing an id column. A row inserted into a users table is hashed by ID, and the router forwards it to the shard responsible for that value. A query like SELECT email from user where id = 4; can go to a single shard, while SELECT email FROM user WHERE id BETWEEN 3 AND 5; may require the router to query multiple shards and merge the results.

VSchema, data topology, and load balancing

PlanetScale says both Vitess for MySQL and Neki for Postgres describe shard layout through JSON metadata. In Vitess, that is VSchema; in Neki, it is the data topology definition. This tells the router which table is sharded, by which column, and using what indexing method.

At this scale, traffic also cannot pass through just one router. PlanetScale says a deployment with 256 shards, 768 servers, and millions of queries per second may need 10 or even 100 proxies, depending on traffic patterns. A Network Load Balancer (NLB) can present a single host or IP to the application and distribute each connection across those routers, while keeping a connection pinned to the same proxy for its lifetime.

The result is that an application can connect through a single string such as mydb.pscale.com, while queries actually flow through an optional NLB, into one of many proxies, and then out to the appropriate shards. PlanetScale’s recommendation is straightforward: for Postgres and MySQL, sharding should start well before 1 petabyte — typically once a database grows beyond a few terabytes.