Hacker News AI · 10/19/2026, 21:53:52
KiviDB Launches: A Rust-based Redis-compatible Memory DB with Vector Search
KiviDB is a multi-threaded, Rust-based memory database that offers full Redis protocol compatibility and built-in vector search. Benchmarks indicate it delivers approximately 9x the GET throughput of Redis 8 on identical hardware, with lower latency than Dragonfly. The project aims to provide developers with a high-performance, easily migratable alternative for caching and retrieval infrastructure.
SOURCE COVERAGEFull Original Report
Contents4 sections
KiviDB is a fast, multi-threaded alternative to Redis® and Valkey, written in Rust. It
speaks the Redis protocol (RESP2 and RESP3), so existing Redis clients, redis-cli and
libraries work unchanged, and it has full-text and vector search built in. It runs every
core on a sharded in-memory key-value design, and persists to snapshots and an optional
append-only file.
On the same 32 cores, KiviDB serves 21 million pipelined GETs per second: about 9× Redis 8 and 2.3× Dragonfly, with under half Dragonfly's p99 latency (benchmarks).
docker run -d -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING # PONGKiviDB listens on 6380, not Redis's 6379, so the two can run side by side; point your
client at that port, or pass --port 6379.
- Protocol: Redis-compatible command surface (see COMMANDS.md for the supported commands)
- Search and vectors: Redis Stack–style
FT.*commands for full-text, tag, numeric and vector (FLAT / HNSW) search - Lua scripting: optional Cargo feature.
EVAL,SCRIPT,FUNCTION,FCALLand related commands are available in builds with--features lua(see Scripting commands (Lua)) - TLS: optional Cargo feature (
--features tls) - Default listen address:
0.0.0.0:6380, with protected mode on - License: GNU Affero General Public License v3 (AGPL-3.0-only), open source; using KiviDB does not put your application under the AGPL; see License
Repository: github.com/kividbio/kividb · Website: kividb.io
How it compares
| KiviDB | Redis 8 | Valkey 8 | Dragonfly | KeyDB | |
|---|---|---|---|---|---|
| License | AGPL-3.0 | RSALv2, SSPLv1 or AGPL-3.0 | BSD-3-Clause | BSL 1.1 | BSD-3-Clause |
| Language | Rust | C | C | C++ | C++ |
| Commands run on | every core (sharded) | one thread (I/O threads) | one thread (I/O threads) | every core (shared-nothing) | several threads |
Full-text and vector search (FT.*) | built in | built in (Query Engine) | separate module | built in | no |
| Lua scripting | lua build | yes | yes | yes | yes |
As of October 2026. Something out of date or wrong? Please open an issue.
Performance
<a href="assets/benchmarks/kividb-benchmarks.mp4"> <img src="assets/benchmarks/kividb-benchmarks.webp" alt="KiviDB benchmarks: throughput, latency, vector search and vector ingest" width="720"> </a>Throughput, latency, vector search and vector ingest. Click for the full-resolution video.
All figures below are from one session in October 2026 on AWS Graviton3 bare metal: the
server on a c7gn.metal (64 vCPU), confined to 32 cores, and the load generator on a
second c7gn.metal in the same placement group. Each engine ran alone on the server,
one after another.
Key-value
memtier_benchmark through kivi-benchmark's run-matrix.sh: 10 million keys, 100-byte
values, 30 s a scenario, mean of two rounds; 300 connections pipelined, 1,200 without
pipelining.
| ops/s | KiviDB 1.1.0 | Dragonfly 2.0.2 | Redis 8.10 | Redis Cluster (32 shards) |
|---|---|---|---|---|
| GET, pipeline 16 | 21.2M | 9.1M | 2.4M | 4.7M |
| SET, pipeline 16 | 19.2M | 8.5M | 2.0M | 4.7M |
| GET, no pipelining | 3.07M | 3.35M | 1.32M | 1.46M |
| SET, no pipelining | 3.12M | 3.38M | 1.54M | 1.46M |
| p99 latency, GET / SET, pipeline 16 | 0.36 / 0.42 ms | 0.88 / 1.07 ms | 2.2 / 2.7 ms | |
| Memory per key | 177 B | 134 B | 178 B | 183 B |
Vector search
redis/vector-db-benchmark on glove-25-angular (1.18M vectors, 25 dimensions): HNSW with M=16 and EF_CONSTRUCTION=256, 100 clients uploading in batches of 64, then queries at ef 64, 128, 256 and 512.
<picture> <source media="(prefers-color-scheme: dark)" srcset="assets/benchmarks/vector-qps-recall-dark.png"> <img src="assets/benchmarks/vector-qps-recall-light.png" alt="Vector search: queries per second against recall" width="720"> </picture>| KiviDB 1.1.0 | Dragonfly 2.0.2 | Redis 8.10 (query engine) | |
|---|---|---|---|
| Queries/s at ef 64 (recall@10) | 59.3k (0.943) | 41.3k (0.912) | 31.8k (0.912) |
| Queries/s at ef 128 | 50.7k (0.961) | 40.3k (0.937) | 28.9k (0.937) |
| Queries/s at ef 256 | 31.5k (0.989) | 36.2k (0.979) | 21.1k (0.979) |
| Queries/s at ef 512 | 18.7k (0.998) | 29.8k (0.995) | 13.7k (0.995) |
| Ingest and index build | 31 s | 13 s | 38 s |
| Memory after ingest | 1.66 GB | 1.13 GB | 1.07 GB |
- Methodology and scripts: kivi-benchmark
- The most recent automated run: benchmarks/LATEST.md
Results depend on the environment. Treat published figures as one controlled capture, not a guarantee, and measure on your own hardware and workload.
（注：更多技术实现细节与完整 API 文档请查阅原项目 README）
作者发帖说明（HN）：
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 : [h...