Nice project but I am a bit curious about the 31x performance gain over Redis. Antirez has always been an optimisation guru for a lot of us and benching as high as 31x on simple pipeline SET seems absurd (in the good sense of the term here). I can see in the generated README that the start script is using NUMA settask to pin down the number of cores but running 46 redis instances under the pretence that Redis is mono-threaded is actually not reflecting a correct picture here. Yes the command execution loop is mono-threaded but Redis uses multi-threading on io for example. Therefore, the test would be biased as the thread pool would become completely starved. A simple way to look into this would be to dump the CPU wait ops in the benchmark as well to truly understand what's justifying the 31x performance gain.
Kudos on the project launch! I can share my experience from when I was evaluating multi-threaded architectures for Dragonfly back in 2022.
At the time, I had a choice: go down the KeyDB path and suffer from lock contention in real-world use cases, or go with a shared-nothing approach. The latter paid a somewhat heavy price for inter-thread communication, but when combined with a carefully chosen transactional framework could truly become a seamless Redis drop-in replacement. I chose the shared-nothing model.
"Dragonfly removes locks and pays the cost of message passing; KiviDB keeps locks but makes them so fine-grained that they rarely collide and never need to move a request between threads."
Reading this sentence, I immediately saw where it fits into the broader taxonomy of in-memory store architectures. KeyDB, Garnet, and KiviDB share the same foundation: employing fine-grained locks. The choice of programming language (Rust, C#, C++) is less important as it's the underlying architecture that dictates the trade-offs.
With lock-based approaches, features like MULTI/EXEC, Lua scripts, and multi-key operations introduce severe contention that becomes hard to manage. Furthermore, background tasks such as snapshotting, full replication sync, and memory defragmentation are more difficult to implement efficiently when relying on low-level locks.
On the other hand, I would definitely opt for a shared-everything architecture like KiviDB's if I were designing Memcached today - a minimalist key-value store without complex multi-key commands, replication, or snapshotting requirements.
thanks for sharing your thoughts, you have the architecture right, kividb uses shared everything with fine-grained locks, similar to keydb and garrnet. it uses 8 shards per core, each with a hash map behind an rwlock, with separate locks for collection values. we lock all relevant shards in a fixed order. Multi and Exec and arbitrary-key scripts run behind a server-wide exclusive gate, so the transaction-heavy workloads serialize and also lua scripts with shared hash tags can run in parallel, which works well for use cases like bullmq. and for snapshots, we are avoiding forks and copy-on-write memory spikes by capturing immutable string references but the tradeoff is a write pause that grows with key count, which is not an issue with dargonfly for it's non-blocking snapshotting. Please do try this design with dragonfly as it is also a replacement to memcache which kividb isn't yet, haha
that will be part of the next benchmark run, my previous run showed kividb was head to head with Garnet, it was not better but also wasn't worse either. But I haven't tested it with kividb 1.1.0 yet
I did run a benchmark against Valkey 9.1.2 with --io-threads 8 earlier, I will rerun it soon, but these were the results from the previous run, I haven’t been able to find someone who can independently verify these so if you would like then please proceed:
At 100 B GET and pipeline 16, valkey is at 1.61M against 19.71M ops/s for kividb. For 1 KB GET, pipeline 16 it was 1.44M against 8.95M and at 100 B GET, no pipelining: 0.99M against 3.11M, but at pipeline 1 the load generator was the limit for the fast engines, so that row undersells all of them
Values were 100 B and 1 KB, so the small case is covered but not 2 KB. That run only did strings and MSET and MGET. lists and hashes aren't in it yet. Both are a fair ask, and I'll add 2 KB values and LPUSH/LRANGE and HSET/HGETALL scenarios to the harness for the next run.
Thanks edoceo, this benchmark was run on an earlier version of kividb, which still had several memory management issues, for example, in this test, the memory per key was around 250B as compared to 178B for redis, so probably that's why, I have not been able to publish these numbers yet, but since several people have raised this, I will be prioritizing it
Just adding my benchmarking repo, that contains terraform code and scripts using which I performed the benchmarks, helpful for re-evaluating and verifying the numbers published on our website. And possibly to learn where we might have gone wrong.
From one Murtaza (who also worked on NoSql DBs) to another, congrats on the launch! The benchmark numbers are impressive. For a database, as always, durability guarantees (in case of in-memory setups, this would translate to any of the "reasonable" forms of consistency, like read your writes) trump speed. Hopefully, there's some focus on that, too.
Shameless plug:
Did something similar but with on disk storage as an experiment ( https://github.com/yannick/marekvs ). Mostly geared towards testing interesting datastructures.
thanks, appreciate it! marekvs looks really interesting, especially the crdt side, Orswot and PN counters for incr commands. That’s a direction I haven’t tried with kividb tbh. I would love to see these ideas land in at some point. Are you up for contributing? also let me know how it goes when you try kividb, any rough edges you hit are useful to me as well.
happy to talk, sent you a message
i also have a few other project such as a alternative to turbopuffer and another disk based search/vector search engine lingering.
Nice. I am curious if you would seek to maintain this with some kind of a foundation(apache)
based funding or keep it internal to your work?
> I used AI a lot, but I was the one making the design decisions based on the tests that claude picked from my history of troubleshooting sessions as part of my job.
Cool, this seemed like a good learning experience, learning from testing it in a real world. I wonder if you plan to write up some of the experience in a blog or something?
I haven't given much thought to it, but sounds like a good idea, I do have a blog section on my website, but I have kept it only for announcements and benchmark comparisons, and to boost the website for search appearances, But this seems a good idea, I will post the blog. Just to make it clear, it did start it as a side project, but currently I am persuing it full time. New contributors are always welcome
I don't care about AI being used to build it, or to write the site, but I do care about why its so much faster than redis. Antirez is pretty performance-obsessed. But outside of that, this looks like a fun project.
It is mostly because kividb can utilize all the cores you can allow on a machine, whereas Antirez built redis as a single threaded cache. The fairer comparison imo would be with redis cluster row in the table where 32 Redis shards were created, one per core, resulting 4.7M pipelined GETs/s. KiviDB’s 21.2M against that is down to not paying for cluster routing and per-shard overhead, and to io_uring batching.
OOM was a big one, because when we had large dataset for example 96G on a 126G dragonfly pod, when it was time for a snapshot, it created a copy within its memory before storing it to the disk, this was during dragonfly 1.35, not sure if they fixed it with 2.0. GC pauses was a second problem we faced, we noticed it from the dips in grafana charts for the read throughputs and it was on a schedule. Do let me know if the issues you faced are solved with kividb, we also have an operator for it as well https://github.com/kividbio/kividb-operator
a correction here, it wasn't the GC pauses within dragonfly itself, there were periodic dips in the throughput graphs overtime, that looked similar to GC pauses, but can't be the case as dragonfly does manual memory management. For the memory spikes around snapshots though, I certainly noticed them.
I haven’t tested against it, that will be next, i will run the benchmarks on the same method and publish the results, or if you want to, you can as well. Even if it performs poorly, I will report that too like we did with dragonfly.
That's true, however the intention to run the benchmark would be against most of the widely used commands and see if there is any command or use case where kividb might be a better fit than kvrocks. strictly speaking from hardware performance, it would certainly beat kvrocks in terms of sheer throughput, but in terms of volume where does it stand would be something interesting to experiment.
I don't have that yet, but this week we will running a similar workflow like this one shown https://www.youtube.com/watch?v=DgcBFb4L0dI. We were able to secure enough credits recently to run this, I will be posting a video on youtube as well. But if you would be open to collaborate, let me know.
I thought this project was interesting so I went to the blog and noticed I was reading AI. I am sure the same amount of effort was put into this project.
I am sure that is an impression for many, that is true we did use AI for our blogs, most of our website is built with AI, that was never our focus though, our focus was the database engine itself. But in order for others to find this project, we had to post the blogs. However I can assure you, none of them were auto published, I reviewed each post, verified each fact ourselves before publishing, but I may have mistakes, would you able to share a blog that you might think looks misleading?
Pipelined throughput that high usually means the loadgen is the thing you're measuring. Past ~5M ops/sec we needed 3 separate memtier hosts to keep the client off the critical path. Any p99 numbers alongside it?
Yes, p99s are in the README file in the github repo. at pipeline 16, GET/SET p99 was 0.36/0.42 ms for KiviDB, 0.88/1.07 ms for Dragonfly 2.0.2 and 2.2/2.7 ms for Redis 8.10. That is one of the differentiators, the p99 is sub millisecond
Yes, for building test cases, for code refactoring, and commenting, because it writes cleaner code, but yeah design decisions were mine. The benchmarks I ran were what dragonfly advertises, so scripts for those were written with AI. For redis compatibility, we run redis’ own unit test and e2e test suite with every change to make sure I am not breaking anything each change and you can review it in the repo.
At the time, I had a choice: go down the KeyDB path and suffer from lock contention in real-world use cases, or go with a shared-nothing approach. The latter paid a somewhat heavy price for inter-thread communication, but when combined with a carefully chosen transactional framework could truly become a seamless Redis drop-in replacement. I chose the shared-nothing model.
"Dragonfly removes locks and pays the cost of message passing; KiviDB keeps locks but makes them so fine-grained that they rarely collide and never need to move a request between threads."
Reading this sentence, I immediately saw where it fits into the broader taxonomy of in-memory store architectures. KeyDB, Garnet, and KiviDB share the same foundation: employing fine-grained locks. The choice of programming language (Rust, C#, C++) is less important as it's the underlying architecture that dictates the trade-offs.
With lock-based approaches, features like MULTI/EXEC, Lua scripts, and multi-key operations introduce severe contention that becomes hard to manage. Furthermore, background tasks such as snapshotting, full replication sync, and memory defragmentation are more difficult to implement efficiently when relying on low-level locks.
On the other hand, I would definitely opt for a shared-everything architecture like KiviDB's if I were designing Memcached today - a minimalist key-value store without complex multi-key commands, replication, or snapshotting requirements.
In any case, best of luck with the project!
At 100 B GET and pipeline 16, valkey is at 1.61M against 19.71M ops/s for kividb. For 1 KB GET, pipeline 16 it was 1.44M against 8.95M and at 100 B GET, no pipelining: 0.99M against 3.11M, but at pipeline 1 the load generator was the limit for the fast engines, so that row undersells all of them
Values were 100 B and 1 KB, so the small case is covered but not 2 KB. That run only did strings and MSET and MGET. lists and hashes aren't in it yet. Both are a fair ask, and I'll add 2 KB values and LPUSH/LRANGE and HSET/HGETALL scenarios to the harness for the next run.
https://github.com/kividbio/kivi-benchmark
And impressive benchmarks.will have to try it.
Shameless plug: Did something similar but with on disk storage as an experiment ( https://github.com/yannick/marekvs ). Mostly geared towards testing interesting datastructures.
> I used AI a lot, but I was the one making the design decisions based on the tests that claude picked from my history of troubleshooting sessions as part of my job.
Cool, this seemed like a good learning experience, learning from testing it in a real world. I wonder if you plan to write up some of the experience in a blog or something?
I haven't run into problems with Dragonfly yet, was it only OOM you encountered with it? Garnet I had GC pauses causing problems, so I dropped that.