A Rust Redis clone that actually uses all your cores

What it does

KiviDB is a multi-threaded, in-memory key-value server written in Rust that speaks the Redis protocol (RESP2 and RESP3), so existing Redis clients and redis-cli work unchanged. It runs commands on every core via a sharded design, persists through snapshots and an optional append-only file, and includes Redis Stack–style FT.* commands for full-text (BM25), tag, numeric, and vector search (FLAT or HNSW). It listens on port 6380 by default so it can sit next to a real Redis.

The interesting bit

The persistence story for vectors is unusually thoughtful: snapshots store not just keys and index schemas but the HNSW graph itself, so search quality after a restart matches what you had before shutdown instead of degrading through a rebuild. Also notable: Lua scripting and TLS are compile-time Cargo features rather than always-on baggage — a build without TLS refuses to start if you ask for a TLS port, rather than quietly serving plaintext.

Key highlights

• Claims 21M pipelined GETs/s on 32 cores — about 9× Redis 8 and 2.3× Dragonfly, with p99 latency under half Dragonfly’s (0.36 ms vs 0.88 ms)
• Vector search holds up too: 59.3k queries/s at ef 64 with 0.943 recall@10, beating Dragonfly and Redis 8’s query engine on that workload
• In a ramp-to-saturation test (clients added until the server breaks), it peaked at 2.08M req/s with zero errors and 13.9 ms p99 at 1,600 clients
• Redis Stack–compatible FT.SEARCH with KNN queries, hybrid search, and the same FLOAT32 blob convention as redis-py/numpy
• AGPL-3.0 licensed, with the README explicitly noting that using it doesn’t put your application under the AGPL

Caveats

• The benchmarks are the authors’ own, run on their harness (kivi-benchmark) — the README itself says to treat them as one controlled capture, not a guarantee
• It loses to Dragonfly on some fronts: non-pipelined throughput (~20% below on the Azure run), vector ingest time (31 s vs 13 s), and memory per key (177 B vs 134 B)
• During index rebuilds at startup, most commands return LOADING — a real availability gap after a crash if you didn’t SAVE first

Verdict

Worth a look if you want Redis compatibility plus built-in vector search without running Redis Stack or a separate vector database — especially on many-core machines with pipelined workloads. If your traffic is non-pipelined or you’re memory-tight, Dragonfly’s numbers here are still competitive.