Show HN: KiviDB, a faster Redis-compatible memory database and vector cache

Posted by murtazayusuf 2 days ago

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

Comment by romange 2 days ago

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!

Comment by murtazayusuf 2 days ago

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

Comment by 2 days ago

Comment by edoceo 2 days ago

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)

Comment by esafak 2 days ago

And MS Garnet.

Comment by murtazayusuf 2 days ago

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

Comment by murtazayusuf 2 days ago

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.

Comment by edoceo 2 days ago

This seems a reasonable response but was [dead] so I vouched you. Was dead because it's BS or wrong or...?

Comment by murtazayusuf 2 days ago

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

Comment by murtazayusuf 2 days ago

And thanks for vouching for me, not sure why it was marked as dead

Comment by murtazayusuf 2 days ago

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

Comment by ignoramous 2 days ago

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.

Comment by murtazayusuf 2 days ago

[dead]

Comment by Shamanoid 2 days ago

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.

Comment by murtazayusuf 2 days ago

[dead]

Comment by 2 days ago

Comment by ghm2180 2 days ago

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?

Comment by justincormack 2 days ago

The Apache foundation does not fund projects, nor do other foundations.

Comment by murtazayusuf 2 days ago

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

Comment by 6622331623 2 days ago

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.

Comment by murtazayusuf 2 days ago

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?

Comment by AtalantaDB 2 days ago

Have you looked into whether the advantage of your DB stems primarily from more efficient I/O batching or from faster command execution after?

And its especially interesting to know whether performance profiling was used for optimization and if so do any flamegraphs still exist?

Comment by murtazayusuf 2 days ago

With 1.1 we are on par when compared only based on command execution, however it terms of IO kividb performs better. As you can see above, at pipeline 1, the performance is slightly worse than Dragonfly, but when pipelined at 16, it reached 21M. I don't have the flamegraphs with me from previous run, but given the similar ask from other hackers in this thread, I am going to release all of it asaic, I haven't yet because I didn't record them in my previous runs especially the 16 vs 1 pipeline numbers.

Comment by yawniek 2 days ago

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.

Comment by murtazayusuf 2 days ago

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.

Comment by yawniek 2 days ago

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.

Comment by shepardrtc 2 days ago

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.

Comment by murtazayusuf 2 days ago

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.

Comment by syepes 2 days ago

How does this compare and benchmark with https://github.com/apache/kvrocks

Comment by murtazayusuf 2 days ago

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.

Comment by sligbad 2 days ago

Well Kvrocks is on disk, not in memory.

Comment by murtazayusuf 2 days ago

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.

Comment by ChocolateGod 2 days ago

Kvrocks is both iirc, since it can cache the rocksdb data in memory.

Comment by porker 2 days ago

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.

Comment by murtazayusuf 2 days ago

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

Comment by murtazayusuf 2 days ago

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.

Comment by kingcauchy 2 days ago

How did overall memory footprint look during ingestion vs Redis? Have any tradeoff graphs as the dataset gets larger and with mixed workloads?

Comment by murtazayusuf 2 days ago

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.

Comment by insiderprint 2 days ago

impressive!

Comment by falconBrisk47 2 days ago

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?

Comment by murtazayusuf 2 days ago

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

Comment by latencyharbor 2 days ago

[flagged]

Comment by hahahoo 2 days ago

[flagged]

Comment by saurilabs 2 days ago

Has there been heavy usage of AI in building this?

Comment by murtazayusuf 2 days ago

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.

Comment by duendefm 2 days ago

nowadays people will have it like either full AI or no AI, guess which one this project went like

Comment by green-salt 2 days ago

there's a .claude/ in the gitignore

Comment by murtazayusuf 2 days ago

Yes correct