PlanetScale's Neki hits 118 million queries per second across 512 Postgres shards

Neki sustains 118.5 million queries per second

PlanetScale has published benchmark numbers for Neki, a distributed database platform it released in platform preview the day before the post went up, reporting a sustained 118,538,803 queries per second across 512 shards holding 1.22 PiB of data. According to the company's blog post, which surfaced on the Hacker News front page, the run lasted 16 minutes and the highest single reading came in at 118,747,267 QPS.

The starting ambition was far smaller. PlanetScale says the team set out to see whether Neki could handle 1 million queries per second, cleared that goal with just five shards, and then kept adding capacity to find where the ceiling was.

How the benchmark was run

The workload was deliberately simple: single-shard point selects fetching one row per query by primary key. There were no writes, joins, or queries spanning multiple shards, and each shard received an isolated stream of work.

The methodology was to target 200,000 QPS per shard and then grow the cluster — first to five shards, then fifty, then 512. Per the post, per-shard throughput held within 0.8 percent between the five-shard and fifty-shard runs, which delivered roughly 1 million and 10 million QPS respectively. At 512 shards the nodes still had headroom, so the team let the load generator use it and each shard settled near 231,000 QPS instead of the 200,000 target.

The configuration behind the peak run, as listed by PlanetScale:

• 512 shards, each a single Postgres primary on an r8g.16xlarge instance
• 480 Neki routers, each on its own 8xlarge instance
• p99 latency of 6.06 ms at the router and 13.95 ms at the client
• 67 errors per second, about one query in 1.8 million
• 15.8 million read IOPS across the fleet
• More than 2 Tb per second of network traffic

What the numbers do and don't prove

PlanetScale is upfront that this is a best-case read benchmark rather than a production simulation. The shards ran primary-only with no replicas, the workload was read-only, and no failover occurred during the measured window. A point-select-by-primary-key workload with no joins or cross-shard coordination is close to the easiest thing a sharded system can execute, so the figure should be read as a ceiling on horizontal read scaling rather than a prediction of mixed-workload behavior.

The company says a follow-up article will cover the engineering effort and the challenges involved in pushing past 100 million QPS.

Why it matters

The headline number is less interesting than the scaling curve underneath it. Going from 5 to 50 to 512 shards, per-shard throughput barely moved, which is the property vendors in this space most want to demonstrate: that the routing tier does not become a bottleneck as the cluster grows. Holding a 6 ms p99 at the router while moving more than 2 Tb per second suggests the 480-router layer kept pace with the fleet.

The run also confirms Neki's Postgres-based architecture, with each shard fronted by a Postgres primary — a notable data point for a company best known for its MySQL-compatible Vitess heritage.

As with any vendor-run benchmark, the figures are self-reported and shaped by the chosen workload, so comparisons with other systems should be made carefully. Even so, sustaining 118 million QPS over 1.22 PiB within a day of a platform preview release sets a high reference point for the rest of the distributed database market to argue with.