TL;DR

KiviDB (kividbio/kividb) is an in-memory key-value server written in Rust that speaks the Redis protocol (RESP2 and RESP3). Existing Redis clients, redis-cli and cluster-aware libraries connect to it unchanged. It runs commands on every CPU core, where Redis runs them on one thread. JSON, time series, vector sets and the Redis Stack–style FT.* full-text and vector search commands are built in, with no modules to load.

Last verified: November 10, 2026. Facts as of that date:

  • 1,037 GitHub stars, 106 forks, 20 contributors. The public repository was created on October 16, 2026; the maker says on Hacker News that work began in February 2026.
  • 71 open issues (issues only; GitHub’s combined counter shows 82 because it also counts open pull requests), and 210 closed.
  • Latest release: v1.2.0, published November 3, 2026. v1.1.3, a week earlier, was a security release fixing three advisories.
  • License: AGPL-3.0-only, with a commercial license from KIVIDB PRIVATE LIMITED for organizations that can’t use AGPL software.

Not run by us: KiviDB would run in our hands-on lab (a throwaway GitHub Actions container), but GitHub refused to start the job today because of an account billing problem. This review is based on the README, the compatibility docs, the 1.2.0 benchmark report, the release notes, the issue tracker and the Hacker News discussion. Every performance number below is the project’s own.

Our verdict: KiviDB is the most thoroughly documented of this year’s Rust Redis replacements. Its compatibility page reads like a list of known bugs, which is what you want from a database. The project reports pipelined throughput far above Redis and level with Garnet, filtered vector search well ahead of Dragonfly and Redis, and a small memory rise during snapshots. It is also a few weeks old in public, mostly one maintainer’s work, built with heavy AI assistance, and has already shipped a withdrawn release and a security release. Try it as a cache or an AI-app sidecar (semantic cache, vector store, job queue) where losing the data is survivable. Wait a few more releases before it holds your only copy of anything.

Quick Reference

FieldValue
What it isMulti-threaded, Redis-compatible in-memory database with built-in search, JSON, time series and vector sets
LanguageRust (2024 edition, Rust 1.89+)
ProtocolRESP2 and RESP3; reports itself as Redis 8.10
Default port6380 (not 6379), so it can run beside Redis
PersistenceNative snapshots (dump.kdb) plus optional append-only file; reads Redis dump.rdb
ScalingReplication (including from a Redis primary), Redis cluster protocol; no Sentinel
Build variantsdefault, lua, tls, full (lua,tls)
InstallDocker Hub / GHCR images, .deb / .rpm, Linux and macOS tarballs, Homebrew, Kubernetes operator
LicenseAGPL-3.0-only, or commercial

What KiviDB actually is

Redis executes commands on one thread, so a single Redis process can’t use a 32-core machine; you shard into a Redis Cluster or accept the ceiling. Dragonfly, KeyDB and Microsoft’s Garnet each attacked that ceiling differently. KiviDB is the newest entrant.

According to the maker’s answer on Hacker News, KiviDB is “shared everything with fine-grained locks, similar to KeyDB and Garnet”: eight shards per core, each a hash map behind a read-write lock, with multi-key commands locking shards in a fixed order and MULTI/EXEC running behind a server-wide gate. Dragonfly’s co-creator, who also commented, chose the opposite design (shared-nothing) in 2022. On Linux KiviDB uses io_uring when the kernel allows it and falls back to Tokio otherwise.

The second half of the pitch is AI workloads. The FT.* commands cover BM25 full-text, tag and numeric fields, and vector search with FLAT or HNSW indexes, and snapshots store the HNSW graph so a restart doesn’t rebuild it. The compatibility doc lists frameworks checked with their own Redis test suites, among them LangChain, LangGraph’s checkpointer, LlamaIndex, Mem0, LiteLLM, Semantic Kernel, Spring AI, GPTCache, Dify, RAGFlow, n8n, Celery, BullMQ and Sidekiq. Haystack’s Valkey document store is listed as not compatible (it fails on Redis 8 too).

Getting started

The quickest path is Docker:

docker run -d -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING   # PONG

The image defaults to --protected-mode no, because a container is never reached over loopback. Passing your own flags replaces that default and turns protected mode back on, so set a password when you add arguments:

docker run -p 6380:6380 \
  -v kividb-data:/home/kividb \
  ghcr.io/kividbio/kividb --aof --requirepass "change-me"

Operational details from the README worth knowing:

  • The image is distroless: no shell, no redis-cli. Connect from a sidecar, e.g. docker run --rm -it --network container:<name> redis redis-cli -p 6380.
  • Docker’s default seccomp profile blocks io_uring, so in a container KiviDB uses its Tokio fallback unless you loosen seccomp.
  • The .deb and .rpm packages install a systemd unit and a config that listens on loopback only.
  • From 1.2.0, release files and images carry GitHub artifact attestations (gh attestation verify ... --repo kividbio/kividb).
  • A release build makes one HTTPS request to GitHub at startup to check for a newer version. The README says nothing is sent beyond the request and a kividb/<version> user agent; switch it off with --update-check no or KIVIDB_NO_UPDATE_CHECK=1.

Vector search, the Redis Stack way

If you’ve used Redis Stack or Redis 8’s query engine, there’s nothing new to learn. The README’s index definition, then a query from redis-py:

redis-cli -p 6380 FT.CREATE idx ON HASH PREFIX 1 doc: SCHEMA \
  vec VECTOR HNSW 10 TYPE FLOAT32 DIM 128 DISTANCE_METRIC COSINE M 16 EF_CONSTRUCTION 128
import numpy as np, redis

r = redis.Redis(port=6380)
v = np.random.rand(128).astype(np.float32)
r.hset("doc:1", mapping={"vec": v.tobytes()})   # FLOAT32 little-endian, DIM x 4 bytes

res = r.execute_command(
    "FT.SEARCH", "idx", "*=>[KNN 10 @vec $q AS score]",
    "PARAMS", "2", "q", v.tobytes(), "SORTBY", "score", "DIALECT", "2",
)

Vectors are raw FLOAT32 bytes in a hash field, the same convention as Redis Stack, so Redis-based vector integrations can work unchanged. Caveats from the docs: run SAVE or BGSAVE after a large ingest, or most commands return LOADING on the next start while the graph rebuilds; INT8/UINT8 vectors aren’t supported; and full-text search has no stemming or phonetic matching.

What the benchmarks say, and who says it

All numbers here come from the project. The 1.2.0 report (Azure VMs, November 1–3, 2026; engines measured on the same machines in the same hour) is the conservative set:

WorkloadKiviDB 1.2.0Best otherRedis 8.10
GET 100 B, pipeline 1610.45M ops/sGarnet 10.69M1.41M
SET 100 B, pipeline 167.94M ops/sGarnet 9.83M1.25M
MSET of 10 keys569K cmd/sGarnet 800K144K
Bytes per key (100 B values, 50M keys)140.7Dragonfly 141.5174.4
Memory added by BGSAVE under writes+10%Dragonfly +0.4%+89%
Filtered vector search, 100 clients4,478 q/sDragonfly 8111,802

The project states where it loses: Garnet on pipelined SET and MSET, Redis Cluster on HSET and INCR, Dragonfly on memory per vector and during snapshots, and Redis on vector ingest and 3–9% more cache reads per second.

The README’s headline (“21 million pipelined GETs per second: about 9× Redis 8 and 2.3× Dragonfly”) comes from an October bare-metal session with KiviDB 1.1.0, without Garnet. The same run puts unpipelined GET and SET slightly below Dragonfly (3.07M vs 3.35M GET), and on glove-25 vectors KiviDB led at low ef but trailed Dragonfly at ef 256 and 512.

What the numbers don’t tell you: nearly all big multipliers are pipelined, so an app doing one request per round trip should expect something closer to Dragonfly-class. And the maker wrote on HN that “the fairer comparison” is Redis Cluster, where 32 shards reached 4.7M pipelined GETs/s against KiviDB’s 21.2M. Harnesses and raw data are public in kivi-benchmark; we found no independent reproduction as of November 10.

Durability: the part that matters more than speed

An HN commenter put it plainly: for a database, durability trumps speed. The release history shows why that matters here:

  • v1.1.1 was withdrawn: under heavy writes with a TTL, background expiry fell behind and memory grew without bound (#87).
  • v1.1.3 fixed three security advisories, including a write to an expired-but-not-yet-removed key that could be acknowledged and lost, and overlapping AOF checkpoints that could lose acknowledged writes.
  • v1.2.0 changed the AOF contract: a write is acknowledged only once its record is in the file, as in Redis. A reply still waits at most 5 seconds; if the disk falls further behind, replies go out first and are counted in aof_acks_before_write.

The 1.2.0 report says its kill, failover and power-loss tests lost zero acknowledged writes. Encouraging, but it’s the project’s own test, a week after a release that fixed write-loss bugs. Migration gotchas: save <points> does nothing (use the AOF or scheduled BGSAVE), and the config parser is strict, so a copied redis.conf with an unknown directive won’t start.

Moving from Redis, and back

KiviDB reads a Redis dump.rdb and can replicate from a Redis primary, so moving in is easy. From the compatibility doc:

  • No easy way back. Redis and Valkey can’t read KiviDB’s DUMP payloads or replicate from it (#450); leaving means a key-by-key copy.
  • Search indexes don’t migrate: rerun FT.CREATE. RDBs with time series, vector sets or Bloom data are refused.
  • No Lua in the default build. BullMQ, Celery, n8n, Dify and LiteLLM’s proxy rate limiter need the lua or full image.
  • No Sentinel, no MODULE LOAD, and KiviDB nodes cluster only with KiviDB nodes.
  • HyperLogLogs use KiviDB’s own format by default; set hll-write-format redis after migrating.

The docs say CI runs Redis 8.10.2’s own test suite on every change: 2,697 tests pass and 6 fail, each a documented difference.

Community reactions

The Show HN thread (October 19, 2026) reached 69 points and 49 comments:

  • Benchmark skepticism, answered with data. One commenter warned that past ~5M ops/s “the loadgen is the thing you’re measuring”; others asked for Valkey, Garnet and kvrocks. The 1.2.0 report added most of those, and Garnet won some.
  • AI-assisted development. A commenter spotted .claude/ in .gitignore; the maker confirmed heavy AI use for tests, refactoring and benchmark scripts, saying the design decisions were his own.
  • Fast bug turnaround. #202, “Performance poor as a cache,” was closed four days after filing and the reporter confirmed the fix on HN. The 1.2.0 report shows a 60.96% hit rate against Redis’s 60.78% on that workload.
  • Why it exists. The maker described Dragonfly pods running out of memory while snapshotting a 96 GB dataset, which explains the focus on snapshot memory.

Honest limitations

  1. Young and concentrated. Public for under a month, 20 contributors. Bus factor matters for a storage engine.
  2. Fast release train. Four releases in eleven days, one withdrawn and one a security release. Pin a version and read the notes.
  3. AGPL. An unmodified KiviDB over the network places no obligations on your app, but some legal teams ban AGPL outright. The commercial license has no published price.
  4. One-way migration until Redis-readable export exists.
  5. Hot-key writes under replication: the docs report about 210,000 writes/s to one key with a replica following, versus 1.1 million without, on 8 CPUs.
  6. Open cluster and persistence edge cases among the 71 open issues (#517, #524, #545).

KiviDB vs the alternatives

KiviDBRedis 8ValkeyDragonflyGarnet
LicenseAGPL-3.0RSALv2 / SSPLv1 / AGPL-3.0BSD-3BSL 1.1MIT
Threadingall cores, fine-grained locksone command threadone command threadshared-nothingmulti-threaded
Built-in vector + full-text searchyesyes (Query Engine)separate moduleyesnot in KiviDB’s comparison
Maturityweeks15+ yearsRedis lineage~4 years~2.5 years

Pick Redis or Valkey for boring and battle-tested. Pick Dragonfly for multi-threading with a longer track record and the lowest snapshot memory. Pick Garnet (Microsoft’s C# server) for the top pipelined write throughput in KiviDB’s own report. Try KiviDB if you want one process to use the whole machine and Redis Stack–style vector search, and can tolerate a young project. For dedicated vector databases, see our vector database comparison.

FAQ

Is KiviDB a drop-in replacement for Redis?

For most client code, yes: RESP2/RESP3, reports itself as Redis 8.10, and fails only six of the Redis test-suite tests its CI runs, according to its docs. The differences are operational: port 6380, no Lua in the default build, no Sentinel or modules, a strict config parser and no export back to Redis.

Can I use KiviDB as a vector database for RAG?

Yes, through FT.* with FLAT or HNSW indexes, and LangChain, LlamaIndex, Mem0 and Semantic Kernel were checked with their own Redis tests. It suits collections that fit in RAM. No INT8 vectors, and the project’s own benchmark shows Dragonfly using less memory per vector.

Does the AGPL license affect my application?

Not if you run KiviDB unmodified and talk to it over the network; the README says your application isn’t a derivative work. Obligations start only if you modify KiviDB and offer that version over a network.

How much faster than Redis is KiviDB really?

On the project’s November 2026 cloud benchmark, about 7× Redis on pipelined 100-byte GETs, roughly level with Garnet. Without pipelining the gap is much smaller, and KiviDB measured slightly below Dragonfly.

Is KiviDB production-ready?

For caches, session stores and AI-app sidecars where data can be rebuilt, it’s a reasonable pilot. For a system of record, the 1.2.0 durability work is promising but very new; keep an exit path.

Bottom line

KiviDB pairs a credible multi-core engine with the most candid documentation of any new Redis-compatible server: it publishes where it loses, which bugs are open and what changed in its durability contract. The speed claims are the project’s own but checkable. The risks are age, a small team and a fast release cadence. Run it beside Redis on port 6380, point a cache or vector workload at it, and check the numbers on your own hardware.

Sources