alt Hacker NewsShow HN: KiviDB, a faster Redis-compatible memory database and vector cache
Hi all,
So I have been working on this project KiviDB from February 2026. It started as a project for me to understand rust, having a product with no GC pauses, memory blow up after snapshots and getting OOM on running pods, and that was actually an issue I faced with Dragonfly. I wanted to have something picking the best of Rust, but also picking the best parts of other alternatives like Garnet and Dragonfly. 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. KiviDB supports both RESP2 and RESP3 protocol. I had some founders credits on my AWS account which helped me with the infra, and running instances I could perform benchmark on.
Its keyspace is sharded across threads, it is multi-threaded in nature, and performs best on Linux due to io_uring, I used the tokio_uring crate for this. It also has tokio fallback for other OS's. I hadn't open sourced it until recently as I felt it was not ready yet, the best way to learn it was to build a cloud managed service for it across all three widely used cloud providers i.e AWS, GCP and azure. Since I used to mainly work with cloud, I had some insights on what would be the best ways for the deployments, how to conduct failovers, manage SLAs, etc. And that's what I took help from claude to fast pace it. The website does look like AI slop but it works for now, given my limited resources, that's all I had. You may check it out at : https://kividb.io, I open sourced the core engine under AGPLv3, didn't want to have just source available, because that is available with other tools too. It supports apprx 98-99% of the redis 8.10 commands, few have issues and you can find them at https://github.com/kividbio/kividb/issues, contributors are welcome.
Now the numbers, for the final benchmark, I used 2 c7gn.metal servers, in the same placement group in us-east1, and I used memtier-benchmark tool for this. The setting was : 10M keys, 100B each, 32 cores in use with both pipeline and un-pipelined runs.
pipeline 16 GET: KiviDB 21.2M ops/sec vs Dragonfly 2.0 9.1M, Redis 8.10 2.4M, Redis Cluster 32 shards 4.7M
When not pipelined, Dragonfly performed slightly better at 3.35M ops/sec vs kividb at 3.07M ops/sec. Memory per key was also slightly worse than dragonfly and almost same as Redis, 177B (kividb) vs 134B (dragonfly) vs 178B (redis).
With vector ingestion times it was slower but when querying, it was faster than most alternatives at lower ef, however slower than dragonfly at high ef. Most of the technical details are mentioned here so you can check it out: https://kividb.io/benchmarks.
easiest way to try it: docker run -d -p 6380:6380 kividb/kividb
I am looking forward to building a community around this, provide better rust based tools, I am open to constructive criticism and value informed opinion. Thanks
Comments
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.
Could you add Valkey to the benchmark? Curious about different key-types too, like list and hash. Also, big values (2KB) and small values (<256B)
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.
Congrats, very cool Project!
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.
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 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.
Congratulations on the project!
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.
How does this compare and benchmark with https://github.com/apache/kvrocks
How did overall memory footprint look during ingestion vs Redis? Have any tradeoff graphs as the dataset gets larger and with mixed workloads?
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.
[flagged]
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?
[flagged]
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.
In any case, best of luck with the project!