Build1 publisher3 min readPublished
PlanetScale's Neki sustained 231,521 queries a second per shard on single-row lookups
The 118.5 million read figure came from 512 PostgreSQL primaries answering primary-key lookups, with no replicas attached and 87.3 percent of reads served from cache at peak. Writes, failover and cross-shard work were not in the test.
The Engineer · Build desk
What happened
- PlanetScale published a benchmark on September 11th saying its Neki database sustained 118,538,803 queries per second across 512 PostgreSQL shards for 16 minutes.
- Each shard ran a single PostgreSQL primary on an AWS r8g.16xlarge with no replicas, and 480 further 8xlarge instances ran the Neki routers.
- Five shards reached 999,624 queries per second and 50 reached 9,923,900, holding per-shard throughput near 200,000 before the 512-shard run measured 231,521 each.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A team weighing a bigger machine against application-level sharding now has a third option worth testing, and the test it needs is the one PlanetScale did not run: its own write path.
- constraint The per-shard number holds only while shard memory keeps hit rates near 87.3 percent; a colder working set moves the binding limit from routers onto storage IOPS.
- exposure Nothing in the configuration exercised replication or failover, so a buyer persuaded by the aggregate figure is accepting an availability story that carries no measurement.
- cost 992 instances produced the number and the benchmark prices none of them, so cost per query at this scale cannot be read off this result.
An application connects to a fleet of Neki routers over the standard PostgreSQL wire protocol. Each router parses the query, resolves the owning shard from a customer-defined data topology, and passes the work to an ordinary PostgreSQL instance [3]. More routers buy query-planning and connection capacity. More shards buy storage and database throughput [4]. In the run PlanetScale published, every request was a primary-key lookup for one row on one shard, with no writes, no joins, no transactions spanning shards and no scatter-gather queries [5].
Per-shard throughput is the figure that shows whether routing scales. Five shards did 999,624 queries per second and 50 did 9,923,900 [7], which is 199,925 and 198,478 per shard [2]. At 512 shards PlanetScale let the instances run past the 200,000 target and measured 231,521 each [8], 15.8 percent above the five-shard figure [3]. Router p99 latency was 6.06 milliseconds and client p99 was 13.95 milliseconds [9].
The cache line explains the shape of the result. PlanetScale's dashboard showed 87.3 percent of reads served from cache at peak [12], and the fleet generated 15.8 million read IOPS [10]. A 12.7 percent miss rate on 118,538,803 queries per second works out to roughly 15.1 million reads per second reaching storage [4], so those two figures are describing the same path.
For 231,521 queries per second per shard to transfer to another workload, all of this has to be true at once. Each query has to resolve to a single shard from its key, because that is the only pattern tested [5]. The hot set has to stay resident well enough to keep hit rates near 87.3 percent [12]. Nothing can be writing to the primary while the reads run [5]. And the shard needs no replica to keep current, because the tested configuration had none [6].
PlanetScale is direct about the boundary: the run does not measure write contention, distributed transactions, replication lag, failover, recovery, or the cost of operating a configuration this size [14]. The control plane that coordinates resharding, upgrades and failover is part of the architecture as announced on August 11th, 2025 [15], and it was not the thing under load here.
Errors ran low. The fleet produced 67 failed queries per second, about one in every 1.8 million attempts [11], which is 64,320 errors across the 16 minutes [5]. The instance count is worth writing down before anyone reasons about unit economics: 512 shard primaries on r8g.16xlarge plus 480 8xlarge routers [6] is 992 machines [1], unpriced in the benchmark [14].
One inconsistency sits in the published material. The dashboard labels the peak configuration as 513 shards and 483 routers, while the benchmark table describes the measured run as 512 shards and 480 routers [13].
The alternatives are the reason any of this gets evaluated. A larger machine postpones the ceiling. Application-level sharding moves the ceiling, at the price of routing logic and operational complexity in application code, and PostgreSQL-compatible distributed databases trade away SQL behavior, extensions and latency instead [17]. Neki keeps standard PostgreSQL under each shard [15], and it entered platform preview on September 10th, one day before engineers Florent Poinsard and Hirad Pourtahmasbi ran the test [2].
What to watch
- A mixed or write-heavy benchmark, and whether per-shard throughput holds when WAL and vacuum work compete with reads on the same primary.
- A failover run with replicas attached, since the 512-shard configuration had none and the control plane owns failover.
- Any published operating cost for a Neki cluster at this size, which the benchmark explicitly leaves out.