KiviDB launches as Rust-based Redis alternative with built-in vector search

A Rust-based Redis alternative goes public

KiviDB, an open-source in-memory database written in Rust, appeared on Hacker News's front page on October 19, presenting itself as a fast alternative to Redis and Valkey. According to the project's GitHub documentation, it speaks the Redis wire protocol in both RESP2 and RESP3 flavours, so existing Redis clients, libraries and redis-cli connect without modification.

The main architectural difference is execution. Where Redis and Valkey run commands on a single thread with separate I/O threads, KiviDB shards its in-memory key-value store across every available core. Dragonfly takes a similar every-core, shared-nothing approach, while KeyDB spreads work over several threads.

The capability the project emphasizes most is search. Redis Stack–style FT.* commands ship in the core server, covering BM25 full-text search, tag and numeric filters, and approximate-nearest-neighbour vector search with a choice of FLAT or HNSW indexes over hash fields.

Self-reported benchmarks

The project publishes benchmark results from October 2026, run on AWS Graviton3 bare-metal machines: the server, a c7gn.metal with 64 vCPUs confined to 32 cores, was loaded by a second identical machine using memtier_benchmark driven by the project's own scripts. On pipelined GETs (pipeline depth 16, 300 connections, 10 million keys of 100 bytes), KiviDB 1.1.0 reportedly served 21.2 million operations per second against 9.1 million for Dragonfly 2.0.2, 2.4 million for Redis 8.10 and 4.7 million for a 32-shard Redis Cluster — roughly 9× Redis and 2.3× Dragonfly, matching the headline claim. Reported p99 latency was 0.36 ms for GET and 0.42 ms for SET, less than half of Dragonfly's 0.88/1.07 ms and well below Redis's 2.2/2.7 ms.

The gap narrows considerably without pipelining: Dragonfly served slightly more GETs per second there, 3.35 million versus 3.07 million. KiviDB also uses more memory per key than Dragonfly, 177 bytes against 134, though it is level with Redis's 178. The project itself cautions that results depend on the environment and that its figures represent a single controlled measurement rather than a guarantee, encouraging users to test on their own hardware.

Vector search trade-offs

On the standard glove-25-angular workload (1.18 million vectors, 25 dimensions, HNSW with M=16 and EF_CONSTRUCTION=256), KiviDB led at lower search effort: 59,300 queries per second at ef 64 with recall@10 of 0.943, versus 41,300 for Dragonfly and 31,800 for Redis's query engine. At higher ef values the ordering reverses — at ef 512 Dragonfly served 29,800 queries per second to KiviDB's 18,700 — and Dragonfly also built the index faster (13 seconds versus 31) and used less memory afterwards (1.13 GB versus 1.66 GB). KiviDB's recall was slightly higher at every ef setting tested, which makes the raw throughput comparison a nuanced one.

Usage follows Redis Stack conventions: vectors are stored as little-endian FLOAT32 blobs in hash fields, and KNN lookups run through FT.SEARCH with Dialect 2 and named binary parameters, so existing clients and tutorials largely apply.

Operational details

KiviDB listens on port 6380 rather than Redis's 6379 by default, so it can run alongside an existing Redis instance; protected mode is on by default, as in Redis. Persistence uses native snapshots (dump.kdb) plus an optional append-only file. Notably, snapshots include index schemas and the HNSW graphs, so search quality after a restart matches what existed before shutdown. While indexes rebuild at startup, most commands return a LOADING error.

Lua scripting (EVAL, SCRIPT, FUNCTION, FCALL) and TLS are compile-time Cargo features rather than defaults; a build without TLS refuses to start if a TLS port is requested. On Linux the server uses io_uring where the kernel supports it and falls back to Tokio otherwise. Building requires a stable Rust toolchain — the oldest version the project checks against is Rust 1.89 — and Docker images are published to Docker Hub and the GitHub Container Registry. The project is licensed AGPL-3.0-only, and states that using KiviDB as a database does not place your application under the AGPL.

Why it matters

The Redis-compatible field is crowded — the project's own comparison table lists Valkey, Dragonfly and KeyDB — but KiviDB combines three traits that rarely arrive together: every-core execution, memory safety from Rust, and native full-text plus vector search without a separate module or database. For teams adding retrieval and AI features, a cache that also serves HNSW queries and BM25 search over the same protocol and clients could simplify infrastructure considerably. The caveats are real: this is a v1.1.0 project, the benchmarks are self-run, Dragonfly keeps clear wins in ingest speed, memory footprint and high-accuracy query throughput, and the AGPL licence will give some companies pause. As a release, it is less a verdict than an invitation to measure on your own workload — which is exactly what the project asks for.