KiviDB just went fully open source. It speaks Redis. It runs on every core. It ships with vector search built in. And it’s written in Rust. If you’ve been watching the Redis alternative space — through the license drama, the Valkey fork, the Dragonfly benchmarks — KiviDB is the newest entry worth a serious look. Not because it’s perfect, but because it solves three problems at once that every other alternative only partially addresses.
The Redis Problem, Briefly #
Redis is fast. It is also single-threaded, and on modern multi-core servers, that ceiling is real. The 2024 license change from BSD-3-Clause to SSPL triggered the Linux Foundation-backed Valkey fork and sent cloud providers scrambling — AWS made Valkey the default for new ElastiCache instances within months. Redis Ltd. reversed course to AGPL in May 2025, but trust, once broken, recovers slowly. The net result: developers are actively evaluating alternatives, and the field is now crowded enough that differentiation matters.
What KiviDB Actually Is #
KiviDB is a multi-core in-memory database written in Rust that speaks the Redis protocol (RESP2 and RESP3). Every existing Redis client works against it unchanged. Every redis-cli command you already know works. The only setup difference is the default port: 6380 instead of 6379.
Under the hood, KiviDB shards the keyspace across every available CPU core using a fine-grained locking architecture, combined with io_uring for batched I/O on Linux. The result on 32-core AWS Graviton3 hardware: 21.2 million pipelined GET operations per second versus Redis’s 2.4 million. That is a 9x headline number — but the honest comparison is against Redis Cluster, where the gap narrows to roughly 4.5x. Still meaningful on high-throughput workloads where a single Redis instance is the bottleneck.
p99 latency for pipelined GETs sits at 0.36ms, under half of Dragonfly’s 0.88ms on the same hardware. Non-pipelined scenarios are closer, and the Hacker News thread pushed back on the methodology — the creator engaged directly and provided the corrected Redis Cluster numbers. That kind of transparency is encouraging in an early-stage project.
The Part Most Redis Alternatives Miss: Vector Search #
Here is where KiviDB distinguishes itself from every other entry in this space. It ships with Redis Stack-compatible FT.* commands built directly into the core binary — no module to load, no separate process to manage. That includes HNSW and FLAT approximate nearest-neighbor indexes, BM25 full-text search, tag and numeric filters, and FT.HYBRID for combining full-text and vector queries in a single call.
For teams running retrieval-augmented generation (RAG) pipelines or AI agent memory layers, this matters. The typical stack today is Redis for caching plus a separate vector database for semantic search. KiviDB collapses that into one deployment. Vector search benchmarks: 59.3k queries per second at ef=64 with 0.943 recall on 1.18 million vectors. HNSW graphs are stored in snapshots, so search quality survives restarts.
Dragonfly has vector capabilities but is BSL-licensed — a commercial agreement is required for SaaS use. Redis Stack works but fragments the operational model. KiviDB is the first genuinely open-source option with both Redis compatibility and vector search built in.
Trying It Takes About Ten Seconds #
docker run -p 6380:6380 kividb/kividb:latest
redis-cli -p 6380 PING
From there, your existing Redis client libraries connect on port 6380 without modification. If you need port 6379, that is one line in the config file. Linux packages (.deb, .rpm) and macOS binaries are also available. The project can be built from source via Cargo for the full Rust build experience.
On the AGPL License #
KiviDB uses AGPL-3.0. The important detail: the AGPL network copyleft clause applies to modifications of KiviDB itself, not to applications that use it. Running KiviDB as infrastructure does not impose any license obligation on your application code. If you modify KiviDB and expose those modifications over a network, you must open-source them — but that describes almost no one’s typical use case. Commercial licenses are available for those who need them.
A few limitations worth knowing: startup index rebuilds block most commands until complete; the AOF sync interval is approximately one second, meaning a hard crash can lose that window of writes; and the official KiviDB site drew some criticism on Hacker News for its marketing copy — though the technical substance held up under scrutiny.
Should You Switch? #
If your Redis instance is CPU-bound and you are already evaluating Dragonfly, KiviDB deserves a benchmark run on your actual workload. If you are building AI features and currently running Redis for caching alongside a separate vector database, the consolidation opportunity is real. If you are on Valkey and it is working fine, there is no urgent reason to move.
KiviDB is early — the project launched in February 2026 and only reached open source this month. The benchmarks are promising and the architecture is sound, but production hardening takes time. Watch for the missing Valkey and Garnet comparisons when they arrive. For now, it is worth running in staging.