Read the discussion on HN. A full-thread summary is not available yet.
kividbio
kividb
Rust2026–2026
kividbio / kividb
kividb
A fast, multi-threaded Redis® and Valkey alternative written in Rust: drop-in compatible, with full-text and vector search built in
2Distinct people
3Mentions
0Explicit recommenders
1.1KGitHub stars
What to know before exploring
What it is
A fast, multi-threaded Redis® and Valkey alternative written in Rust: drop-in compatible, with full-text and vector search built in
GitHub
Where it is used
The last source check was inconclusive. This does not establish whether a product uses it.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
Mentions over time
HN mentions by day3 dated mentions
Observed mentions: 2026-10-19 13:53:52 UTC to 2026-11-01 10:36:48 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Oct 19 | 2026-10-19 00:00:00 UTC | 2026-10-20 00:00:00 UTC | 1 | 1 | 0 |
| Oct 20 | 2026-10-20 00:00:00 UTC | 2026-10-21 00:00:00 UTC | 0 | 0 | 0 |
| Oct 21 | 2026-10-21 00:00:00 UTC | 2026-10-22 00:00:00 UTC | 0 | 0 | 0 |
| Oct 22 | 2026-10-22 00:00:00 UTC | 2026-10-23 00:00:00 UTC | 0 | 0 | 0 |
| Oct 23 | 2026-10-23 00:00:00 UTC | 2026-10-24 00:00:00 UTC | 0 | 0 | 0 |
| Oct 24 | 2026-10-24 00:00:00 UTC | 2026-10-25 00:00:00 UTC | 0 | 0 | 0 |
| Oct 25 | 2026-10-25 00:00:00 UTC | 2026-10-26 00:00:00 UTC | 0 | 0 | 0 |
| Oct 26 | 2026-10-26 00:00:00 UTC | 2026-10-27 00:00:00 UTC | 0 | 0 | 0 |
| Oct 27 | 2026-10-27 00:00:00 UTC | 2026-10-28 00:00:00 UTC | 0 | 0 | 0 |
| Oct 28 | 2026-10-28 00:00:00 UTC | 2026-10-29 00:00:00 UTC | 0 | 0 | 0 |
| Oct 29 | 2026-10-29 00:00:00 UTC | 2026-10-30 00:00:00 UTC | 0 | 0 | 0 |
| Oct 30 | 2026-10-30 00:00:00 UTC | 2026-10-31 00:00:00 UTC | 1 | 0 | 1 |
| Oct 31 | 2026-10-31 00:00:00 UTC | 2026-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 1 | 2026-11-01 00:00:00 UTC | 2026-11-02 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
3 sourcesMUmurtazayusuf·Nov 1, 2026
Thanks for raising this, we are pushing a fix in the new 1.2 release. These were the reproduced the results from the release candidate https://github.com/kividbio/kividb/issues/202#issuecomment-6...
In Show HN: KiviDB, a faster Redis-compatible memory database and vector cachePerformance poor as a cache, redis is 7 times better:
https://github.com/kividbio/kividb/issues/202
In Show HN: KiviDB, a faster Redis-compatible memory database and vector cacheShow 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 Li
Read the rest
nux 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