PlanetScale's Neki Hits 118 Million Queries per Second Across 512 Shards
118M Queries per Second on Neki
PlanetScale benchmarked its new Neki database, scaling from 5 to 512 shards to reach 118.5 million queries per second on 1.22 PiB of data. The workload was simple: single-shard point selects by primary key, no writes or joins. Each shard sustained about 231k QPS, with p99 latency of 6.06ms at the router and 13.95ms at the client. The run was read-only, primary-only, with no failover.
Ten times the shards, ten times the throughput. Then ten times again.
- farazbabar
In 2015, I was able to get to 1 million read/write queries per second on only a couple nodes and tested this with multiple databases, it required (at the time) decent network tuning and node placement inside AWS but it cost me about 10 to 15 dollars per run if I recall correctly, obviously there is the matter of scaling such performance and so I want to recognize the engineering effort gone into this but this is too much money. This reminds of when one of my teams used Hadoop to process only a a few terabytes of offline data and were able to process the WHOLE THING in only a few hours. I did not have the heart or courage to tell them during the demo that this was overkill, but I did write a very simple (and small) piece of code that could extract all the signals from the offline files in mere seconds with careful network planning and storage optimization and invited them for a demo/lunch and learn next week.
- jamesblonde
In 2015, MySQL Cluster (NDB Cluster engine) benchmarked 200m transactions/second on commodity hardware [ref]. It was read-committed transactions, not snapshot isolation, but still impressive. NDB has now become RonDB, but is still based on a non-blocking 2-phase commit protocol and is GPL-v2.
RonDB now has support for infiniband, so ought to blow through the 1B ops/sec. For reference, that is 1 GHz of transactions/sec.
[ref] https://www.slideshare.net/frazerClement/200-million-qps-on-...
- stephenlf
I watched an interview that Casey Muratori did with Tyler Cloutier (SpacetimeDB founder and spokesperson) [1]. One of the points that Tyler is that, given modern CPU architecture with cache lines, a distributed database needs to fan out to at least 50-100 nodes to beat the throughput of a cache-optimized, single node database.
It’s cool to see the flip side of that argument. Planet scale is answering the question, “what does it look like when you DO fan out your workload to >100 nodes?”
There’s a place for both technologies. Very cool stuff.
- danbruc
87.3 % served from cache. Does that mean it returned a result existing in the cache because the very same query was executed before? Probably still a relevant result, if you have to process millions of queries every second, it seems not unlikely that you will see a lot of repeated queries. But at that point you are measuring cache performance more than query performance. But unless you run some standardized query benchmark, a single queries per second number is not that informative anyway because query complexity and therefore execution time can span many others of magnitude. Looking up a name by ID and aggregating across a billion rows from seventeen tables joined together are both a single query.
- cbg0
I did some quick ChatGPT math for the same performance/storage as the benchmark:
Neki 1 primary + 2 replicas: ~$5.0M/month (just the AWS bill)
Google Spanner w/ 3 replicas built in: ~$3.85M/month