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 articleNeki solves the scaling limits of single-instance Postgres without sacrificing compatibility or forcing application-level sharding. It provides a managed path to horizontal scaling with online operations, making it easier to handle massive workloads while keeping standard Postgres tools.
Understanding sharded query lifecycles is essential for engineers scaling relational databases. It reveals the trade-offs in query routing and aggregation necessary for high-performance distributed systems.
Neki enables Postgres to scale horizontally by decoupling connection management and query routing from the core engine. It allows developers to use standard drivers while transparently handling sharding, complex distributed queries, and high connection counts.
Large tables in Postgres create systemic risks, from vacuum bloat to transaction ID wraparound. Understanding how to mitigate these through partitioning or sharding is critical for maintaining high-availability systems as data scales beyond the limits of vertical hardware.