KiviDB is an in-memory database that speaks the Redis protocol. Any Redis client, library or tool works against it unchanged. The difference is underneath: KiviDB is written in Rust and uses a sharded, multi-core engine, where Redis executes commands on a single thread.
As of version 1.1.0, the entire engine is open source under the GNU AGPLv3.
Repo: github.com/kividbio/kividb
Why we open-sourced it
KiviDB shipped as a closed binary for its first few months. The benchmarks and scripts were public, but the feedback from engineers was consistent: a database sits at the core of a production system, and teams won't put something there that they can't read.
That's a reasonable position. Benchmarks show what software does under one set of conditions. Source shows how it behaves under all the others: failure paths, edge cases, persistence, replication. So from 1.1.0 the whole engine is public.
What's in it
- Redis protocol (RESP): strings, hashes, lists, sets, sorted sets, streams, pub/sub, transactions, ACLs. The full list is in COMMANDS.md.
-
Search and vectors: Redis Stack-style
FT.*commands for BM25 full-text, tag and numeric indexes, and FLAT or HNSW vector search, including hybrid queries. -
Persistence: native snapshots (
dump.kdb) plus an optional append-only file. HNSW graphs are stored in snapshots, so vector search quality after a restart matches what you had before shutdown. - High availability: replication, and cluster mode with gossip, failure detection and failover.
- Security: ACLs, TLS with mutual authentication, and protected mode on by default.
-
Optional Lua:
EVAL,FUNCTION,FCALLand related commands in builds with--features lua. - I/O: io_uring on Linux when the kernel allows it, with a Tokio fallback.
-
Packaging: binaries for Linux and macOS (x86_64 and ARM64),
.deband.rpmpackages, and Docker images on Docker Hub and GHCR.
BullMQ and Sidekiq both pass their own test suites against KiviDB.
Run it
docker run -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING
The default port is 6380, so it can sit next to an existing Redis on 6379 while you try it.
From Python, nothing changes except the port:
import redis
r = redis.Redis(host="localhost", port=6380)
r.set("greeting", "hello")
print(r.get("greeting"))
Node with ioredis:
import Redis from "ioredis";
const r = new Redis({ port: 6380 });
await r.set("greeting", "hello");
console.log(await r.get("greeting"));
Vector search in a few lines
Vectors are stored as raw FLOAT32 bytes in a hash field, the same convention as Redis Stack, so existing tutorials carry over.
import numpy as np
import redis
r = redis.Redis(port=6380)
r.execute_command(
"FT.CREATE", "idx", "ON", "HASH", "PREFIX", "1", "doc:",
"SCHEMA", "vec", "VECTOR", "HNSW", "6",
"TYPE", "FLOAT32", "DIM", "4", "DISTANCE_METRIC", "COSINE",
)
docs = {
"doc:1": [0.1, 0.2, 0.3, 0.4],
"doc:2": [0.9, 0.1, 0.0, 0.2],
"doc:3": [0.1, 0.25, 0.3, 0.35],
}
for key, v in docs.items():
r.hset(key, mapping={"vec": np.array(v, dtype=np.float32).tobytes()})
q = np.array([0.1, 0.2, 0.3, 0.4], dtype=np.float32).tobytes()
print(r.execute_command(
"FT.SEARCH", "idx", "*=>[KNN 2 @vec $q]",
"PARAMS", "2", "q", q, "DIALECT", "2",
))
After a large ingest, run SAVE or BGSAVE so the next start loads the HNSW graph from disk instead of rebuilding it.
Benchmarks, including where we lose
All figures are from one session in October 2026 on AWS Graviton3 bare metal: the server on a c7gn.metal limited to 32 cores, and the load generator on a second c7gn.metal in the same placement group. Each engine ran alone, one after another. memtier_benchmark, 10 million keys, 100-byte values.
| 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 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 on glove-25-angular (1.18M vectors, HNSW M=16, EF_CONSTRUCTION=256):
| KiviDB 1.1.0 | Dragonfly 2.0.2 | Redis 8.10 | |
|---|---|---|---|
| QPS at ef 64 (recall@10) | 59.3K (0.943) | 41.3K (0.912) | 31.8K (0.912) |
| QPS at ef 512 (recall@10) | 18.7K (0.998) | 29.8K (0.995) | 13.7K (0.995) |
| Ingest and index build | 31 s | 13 s | 38 s |
How to read this:
- KiviDB's lead is largest with pipelining. Without it, Dragonfly is slightly ahead.
- Dragonfly uses less memory per key and builds vector indexes faster.
- The Redis Cluster column is there because comparing a multi-core engine with a single Redis process isn't the whole story. A 32-shard cluster on the same machine is the fairer "all cores" baseline.
- The pipelined runs used a fixed 300 connections, which bounds that number rather than the engine. An independent benchmark now in progress sweeps connection counts instead.
Methodology, scripts and raw output: kivi-benchmark. Results depend on hardware and workload, so measure on yours.
On the license
KiviDB is AGPL-3.0-only.
- Using KiviDB as your database does not put your application under the AGPL. An app talking to KiviDB over the network is a separate program, whether it's open source or closed, commercial or not.
- If you modify KiviDB itself and offer that modified version to others over a network, you must offer them its source.
- A commercial license is available for organisations that can't use AGPL software.
- Contributions are accepted under a CLA, so the commercial license can exist alongside the open one. Every version released under the AGPLv3 stays available under the AGPLv3.
Contributing
Build from source with stable Rust (1.89 or newer):
git clone https://github.com/kividbio/kividb.git
cd kividb
cargo build --release
./target/release/kividb
CONTRIBUTING.md covers tests and the PR process. Bug reports with a reproduction are especially useful, and security issues go through SECURITY.md rather than public issues.
Repo: github.com/kividbio/kividb · Website: kividb.io
Redis® is a registered trademark of Redis Ltd. KiviDB is not affiliated with Redis Ltd.
Top comments (0)