This benchmark proves Neki's ability to achieve massive horizontal scalability and extreme throughput for Postgres workloads. It demonstrates that petabyte-scale data can be managed with linear performance gains, providing a blueprint for the world's most demanding high-concurrency systems.
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.
r8g.16xlarge8xlarge instanceWorth being clear about this run: the shards were primary-only with no replicas, the workload is read-only across queries ranging in complexity, and we did not fail over during the measured window.
We will go into details on the engineering effort and interesting challenges we faced along the way to reaching 100 million QPS in a future article.
Continue reading on the original blog to support the author
Read full articleEfficient sharding requires co-locating related data to minimize cross-shard joins and transactions. Understanding shard groups allows engineers to design scalable database architectures that maintain high performance even as data volume and query complexity grow.
These updates bridge the gap between traditional Postgres and distributed sharding. With read-only replicas, Azure support, and massive performance boosts to bulk writes, Neki offers a scalable path for Postgres workloads without sacrificing SQL compatibility or developer experience.
Maintaining Postgres semantics in a sharded environment is complex. This article explains how to handle volatile expressions like sequences and timestamps to ensure data consistency and correctness across distributed shards without sacrificing performance.
This expansion allows Azure-based teams to utilize PlanetScale's managed database features with low latency. The technical implementation highlights sophisticated Kubernetes networking strategies to overcome cloud provider IP limitations at scale.