From Planetscale · · 1m 20s
118 million queries per second
PlanetScale pushed its new Neki database to 512 shards and watched throughput scale almost perfectly linearly.
In brief
PlanetScale pushed its new Neki database to 512 shards and watched throughput scale almost perfectly linearly. When each shard's workload is isolated, adding shards adds throughput in a straight line: 10x the shards gave 10x the queries, twice over. Originally reported by Planetscale.
A million was too easy
Neki hit platform preview, and the team celebrated by aiming for 1 million queries per second. Five shards got there almost immediately, so they kept going.
“We hit this goal pretty quickly on 5 shards and decided to see how much further we could push it.”
The simplest possible query
One point select per query, a single row fetched by primary key. No writes, no joins, nothing spanning more than one shard, so every shard's load stayed isolated.
“A single-shard point select, one row fetched per-query by primary key.”
Five, fifty, five hundred
The target was 200k QPS per shard, then grow the cluster. Going from 5 shards to 50, the per-shard rate held within 0.8%.
“Ten times the shards, ten times the throughput. Then ten times again.”
Headroom to spare
At 512 shards the hardware still had room, so they let the load generator take it. Each shard settled at 231k QPS instead of the 200k target.
What 118.5 million looks like
Sustained for 16 minutes: 512 Postgres primaries, 480 routers, 1.22 PiB of data, 15.8M read IOPS, over 2 Tb per second on the network.
“p99 latency of 6.06ms at the router and 13.95ms at the client”
The fine print they own
Shards ran primary-only with no replicas, the workload was read-only, and nothing failed over during the measured window. Errors ran at one query in 1.8 million.
“we did not fail over during the measured window”
The bottom line
When each shard's workload is isolated, adding shards adds throughput in a straight line: 10x the shards gave 10x the queries, twice over.
