Show HN: KiviDB, a faster Redis-compatible memory database and vector cache
github.comHi 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
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.
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?
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)
And MS Garnet.
How did overall memory footprint look during ingestion vs Redis? Have any tradeoff graphs as the dataset gets larger and with mixed workloads?
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.
https://github.com/kividbio/kivi-benchmark
How does this compare and benchmark with https://github.com/apache/kvrocks
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.
Well Kvrocks is on disk, not in memory.
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.
[delayed]
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?
Has there been heavy usage of AI in building this?
there's a .claude/ in the gitignore
Yes correct
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.