← Back to articles

118M Queries per Second on Neki

2026-09-11 | original

read original get Designing Data-Intensive Applications (Martin Kleppmann) → more articles

Why This Matters

PlanetScale's newly previewed Neki demonstrated near-linear horizontal scaling for Postgres, sustaining 118.5 million queries per second across 512 shards and 1.22 PiB of data. The result signals that sharded Postgres can credibly target the extreme-scale workloads previously associated with MySQL/Vitess or NoSQL systems, though the benchmark was deliberately simple and should be read with that caveat.

Key Takeaways

Scaling from 5 to 50 to 512 shards held per-shard throughput nearly constant (within 0.8% up to 50 shards), showing linear scale-out for isolated single-shard reads.
The run sustained 118.5M QPS for 16 minutes with 6.06ms p99 router latency, 15.8M read IOPS, and roughly one error per 1.8 million queries.
Caveats matter: the test was read-only point selects by primary key, with no writes, joins, cross-shard queries, replicas, or failovers during measurement.

Worth a Look

Designing Data-Intensive Applications (Martin Kleppmann) — If benchmarks like 118M QPS across 512 shards fascinate you, this is the book that explains why sharding, replication and partitioning behave the way they do. Kleppmann walks through the tradeoffs behind scaling databases horizontally, making stories like this Neki run far more readable. A staple on any backend engineer's shelf.

See Designing Data-Intensive Applications (Martin Kleppmann) on Amazon → Affiliate link — we may earn a commission on purchases, at no extra cost to you. Product picked by AI based on this article; it is not a tested recommendation.

Florent Poinsard, Hirad Pourtahmasbi | September 11, 2026

We released Neki in platform preview yesterday. To celebrate the release, we wanted to test out running 1 million queries per second on Neki. We hit this goal pretty quickly on 5 shards and decided to see how much further we could push it.

This next run ended with 512 shards running 118 million queries per second with 1.22 PiB of data.

The benchmark was very simple. A single-shard point select, one row fetched per-query by primary key. No writes, joins, or cross-shard queries. The workload that each shard receives is isolated, in that there are no single queries that span multiple shards.

Our target was to sustain 200k QPS on each shard, and then grow the cluster to increase throughput. Five shards, then fifty, then 512.

Shards Routers Delivered QPS QPS per shard 5 12 999,624 199,925 50 48 9,923,900 198,478 512 480 118,538,803 231,521

Ten times the shards, ten times the throughput. Then ten times again. From 5 shards to 50 the per-shard rate held within 0.8%. At 512 the shards still had headroom, so we let the load generator use it and each shard settled at 231k QPS instead of 200k.

We sustained 118,538,803 QPS for 16 minutes across 512 shards and 1.22 PiB of data. Our largest recording was 118,747,267 .

512 shards, each with one Postgres primary each on an r8g.16xlarge

480 Neki routers, each on its own 8xlarge instance

... continue reading

Explore topics: neki postgres sharding qps benchmark r8g.16xlarge