KiviDB, on the stand

KiviDB is a new in-memory database written in Rust that speaks the Redis protocol, so existing Redis clients and redis-cli work against it unchanged. It runs commands on every CPU core instead of one main thread, and it has Redis Stack–style full-text and vector search (FT.CREATE, FT.SEARCH, HNSW and FLAT indexes) built in. It listens on port 6380, so it can sit next to Redis. Version 1.1.0 came out on October 16, the same day the public repository was created, and its Show HN post reached the Hacker News front page this morning.

It is published by KIVIDB PRIVATE LIMITED, a company in India, under the AGPL-3.0. The README says using KiviDB as your database does not put your application under the AGPL, and the company also sells a commercial license. Nearly all commits so far are by one developer, Murtaza Shajapurwala.

The README's headline: 21.2 million pipelined GETs a second on 32 cores of AWS Graviton3, about 9 times Redis 8 and 2.3 times Dragonfly. Those are the maker's numbers, from a separate load machine. We did not repeat that setup.

The test. MODEL downloaded the Linux release binary, checked it against the published SHA-256, and ran it next to Redis 8.0.2 on an 8-core Linux box. No account, no key. The load generator shared the same cores, so treat our speed numbers as a rough guide.

Compatibility: we sent the same 88 commands to both, covering strings, hashes, lists, sets, sorted sets, streams with consumer groups, HyperLogLog, bitmaps, geo, expiry, transactions and error replies. 87 replies were byte-for-byte identical. The one difference was DUMP: the two use different payload formats, so you can't DUMP from one and RESTORE into the other.

Speed, with redis-benchmark: pipelined GETs ran at 3.42 million a second against Redis's 0.87 million (3.9 times), pipelined SETs at 2.01 million against 0.81 million (2.5 times), and without pipelining about 400,000 a second against about 165,000 (2.4 to 2.5 times).

Vector search: 20,000 vectors of 128 dimensions in an HNSW index, checked against an exact brute-force answer. Recall at 10 was 0.982 at a search width (EF_RUNTIME) of 64 and 0.995 at 200, with median latency under half a millisecond from one Python client. Adding a tag filter kept recall at 1.000 but made queries about 20 times slower (8.45 ms median). Full-text counts matched exactly. After a save and a restart, the vector index came back with the same recall.

The catch. The docs say KiviDB reads a Redis dump.rdb at startup, which is how many people would move over. We wrote one key of each type in Redis 8.0.2 and tried each snapshot. Strings, sets and sorted sets loaded fine. A small hash, f1 v1 f2 v2, loaded without a warning as a set of four numbers that weren't in the original. A list, a set of integers and a stream each stopped KiviDB from starting. To its credit, it refuses to start empty rather than quietly losing a file it can't read. We did not test snapshots from newer Redis builds or from Valkey.

Two defaults to know. Persistence is off unless you turn on the append-only file or save yourself: after a hard kill, a write made two seconds earlier was gone. The save schedule from a Redis config is accepted but ignored. And the server checks GitHub for a newer release each time it starts; --update-check no turns that off.

What we did not test. The Lua and TLS builds, replication, cluster mode, eviction under memory limits, Docker images, large datasets, and the README's 32-core and vector benchmarks.

The verdict. Worth a look if you want Redis commands and vector search in one fast server for a new project or a cache you can rebuild. Don't move existing Redis data by copying dump.rdb yet. Re-load it through your app or a client script, check it, and turn on the AOF.

<!-- tool card: content/tools/kividb.md -->