PlanetScale pushes Neki past 118 million read queries per second on a narrow test

Why it matters

Neki extends PlanetScale's Vitess-derived sharding model into PostgreSQL, opening a larger market for the founders' core technology. The benchmark shows strong horizontal read scaling, while production credibility will depend on writes, replication, failover and cross-shard work.

PlanetScale, founded by Jitendra "Jiten" Vaidya and Sugu Sougoumarane (@ssougou), said in a benchmark published September 11th that its Neki database sustained 118,538,803 queries per second across 512 PostgreSQL shards for 16 minutes.

The figure is the clearest demonstration yet of the founders' attempt to repeat their Vitess playbook with PostgreSQL. Vaidya and Sougoumarane helped create Vitess at YouTube, where PlanetScale says the sharding system scaled the site's MySQL database to petabytes of data across 70,000 nodes and 20 data centers. They founded PlanetScale in 2018 around that work. Neki carries the same basic conviction into a different database: keep familiar database servers underneath, then move routing and horizontal scale into a separate layer.

PlanetScale engineers Florent Poinsard and Hirad Pourtahmasbi (@hiradp) ran the test one day after Neki entered platform preview on September 10th. Poinsard joined PlanetScale as an intern in 2021 before becoming a software engineer, while Pourtahmasbi previously worked on database infrastructure at Pinecone. Their initial target was 1 million queries per second. Five shards nearly reached that mark, so they increased the test to 50 shards and finally 512.

A benchmark built to scale

PlanetScale reported 999,624 queries per second on five shards and 9,923,900 on 50. Per-shard throughput stayed close to 200,000 queries per second in both runs. At 512 shards, PlanetScale let the instances run beyond that target, reaching 231,521 queries per second per shard and 118.5 million in aggregate.

The architecture is designed for that kind of scale-out result. Applications connect to a fleet of Neki routers using the standard PostgreSQL wire protocol. The routers parse each query, identify the appropriate shard through a customer-defined data topology and pass the work to ordinary PostgreSQL instances. More routers add query-planning and connection capacity, while more shards add storage and database throughput.

The measured workload took the shortest route through that architecture. Every request was a primary-key lookup for one row on one shard. There were no writes, joins, transactions spanning shards or scatter-gather queries. Each of the 512 shards had one primary running on an AWS r8g.16xlarge instance, with no replicas. Another 480 8xlarge instances ran the Neki routers.

PlanetScale reported router p99 latency of 6.06 milliseconds and client p99 latency of 13.95 milliseconds. The fleet generated 15.8 million read IOPS and more than 2 terabits per second of network traffic. It also produced 67 errors per second, which works out to roughly one failed query for every 1.8 million attempts.

The dashboard showed 87.3% of reads being served from cache at peak, helping explain why request throughput exceeded the underlying read IOPS. It also labels the peak configuration as 513 shards and 483 routers, while PlanetScale's benchmark table describes the measured run as 512 shards and 480 routers.

Those details put the headline number in its proper box. The result measures whether Neki can keep adding isolated read capacity as PlanetScale adds routers and shards. It does not measure write contention, distributed transactions, replication lag, failover behavior, recovery or the cost of operating a production configuration at this size.

The founders' second sharding act

PlanetScale first announced Neki on August 11th, 2025, describing it as a new architecture rather than a PostgreSQL port of Vitess. Each Neki shard runs standard PostgreSQL. Routers handle distributed planning and routing, sidecars manage pooled connections to each database server, and a control plane coordinates operations such as resharding, upgrades and failover.

That design is PlanetScale's answer to a familiar problem for fast-growing PostgreSQL users. Buying a larger machine postpones the ceiling. Application-level sharding can move the ceiling, although it forces routing logic and operational complexity into application code. Distributed databases with PostgreSQL-compatible interfaces make a different set of trade-offs around SQL behavior, extensions and latency.

Neki asks customers to choose shard keys and describe data placement in a JSON topology. That is explicit work, and poor shard-key choices can create hotspots or force expensive scatter-gather queries. PlanetScale's bet is that experienced operators would prefer visible control over data placement while keeping real PostgreSQL on each shard.

The approach draws directly from the founders' experience with Vitess, which now sits underneath large MySQL installations at businesses including GitHub, Slack, Etsy and Block, according to PlanetScale. Neki gives PlanetScale a route into large PostgreSQL accounts after years of being identified primarily with MySQL infrastructure.

Investors financed the earlier expansion of that thesis. By November 2021, PlanetScale had raised a reported $105 million. Insight Partners led its $30 million Series B, with participation from Andreessen Horowitz and SignalFire. Kleiner Perkins led a $50 million Series C later that year, according to TechCrunch's financing report.

Preview first, production later

PlanetScale is making Neki available through a platform preview and explicitly tells users to keep production-critical workloads away for now. The architecture described for normal use includes a primary and at least two replicas per shard across three availability zones. The benchmark removed those replicas and did not trigger a failover during its measured window.

That makes the preview's next phase more important than another larger QPS number. PlanetScale has shown that its routing layer can distribute a highly parallel read workload while preserving nearly linear throughput as the shard count rises. Production databases bring changing data, uneven keys, long-running transactions, hardware failures and queries that refuse to stay inside one shard.

PlanetScale put those limitations beside the benchmark result, which makes the test useful. Neki's 118.5 million QPS run establishes substantial headroom for its simplest path. The product still has to show that the founders' sharding discipline holds when PostgreSQL workloads become messy, stateful and expensive - exactly the conditions that pushed customers toward Vitess in the first place.