kividbio/kividb

Data

A Redis-compatible in-memory key-value store with built-in full-text and vector search, written in Rust.

784
23
Rust
AGPL-3.0
12 days old

KiviDB is an in-memory key-value database that speaks the Redis protocol (RESP2 and RESP3), so existing Redis clients and redis-cli connect with only a port change. It targets teams already running Redis or Valkey who want multi-core throughput and built-in search rather than a separate search module. It is licensed AGPL-3.0, with a commercial option.

What it does

The server shards keys across every core behind fine-grained locks and persists through snapshots or an optional append-only file. Because it speaks RESP, the migration path is mostly client configuration: it listens on port 6380 by default so it can run beside Redis on 6379, and a migration guide and compatibility page document the differences migration guide, compatibility notes, supported commands.

Search is built in rather than bolted on: Redis Stack–style FT.* commands cover BM25 full-text, tags and numerics, and vector ANN over FLAT or HNSW indexes on hash fields. Vectors are stored as raw little-endian FLOAT32 blobs, the same convention Redis Stack and redis-py use, so existing index code largely carries over.

Persistence and restarts

A native dump.kdb snapshot stores keys, index schemas, and, if you save with indexes populated, the HNSW graph itself, so search quality after restart matches pre-shutdown state instead of being rebuilt from hashes. While indexes are rebuilt at startup, most commands return LOADING; PING and INFO keep working. After a large ingest the docs recommend running SAVE or scheduling BGSAVE so the next start reloads from disk. With AOF enabled, a crash loses roughly the last second of writes; when an AOF exists it becomes the source of truth and the snapshot is not loaded persistence details.

Requirements and constraints

  • Builds are feature-gated. The default variant has no Lua scripting and no TLS; EVAL and related commands error without the lua feature, and a non-TLS build refuses --tls-port rather than serving plaintext. Docker tags and release archives publish each variant separately README.
  • Building needs stable Rust, checked against 1.89. Linux uses io_uring when the kernel allows it and falls back to Tokio otherwise; Docker's default seccomp profile blocks io_uring, so containers get the fallback unless you loosen that profile.
  • Exposure is guarded by protected mode, on by default: without a bind address or password, only loopback clients connect, and remote ones get -DENIED. The Docker image disables it by default and any flags you pass replace that default, so set a password or re-disable it explicitly when overriding protected mode.
  • A startup update check makes one HTTPS request to GitHub's releases page, sending only a kividb/<version> User-Agent; it is disableable by flag, config or environment variable, and debug builds skip it update check docs.

Performance claims

Published figures come from one controlled October 2026 session on AWS Graviton3, with the server confined to 32 cores and each engine run alone: 21.2M pipelined GETs/s versus 9.1M for Dragonfly and 2.4M for Redis 8.10. Without pipelining, KiviDB measured slightly below Dragonfly (3.07M vs 3.35M GETs/s). Vector search led at lower ef values but fell behind Dragonfly at ef 512, and ingest plus index build was slower. The README itself calls the results one capture, not a guarantee, and directs readers to measure on their own hardware benchmarks.

Licence

AGPL-3.0-only: an application that talks to unmodified KiviDB over the network is not covered, but modifying KiviDB and offering that version over a network requires publishing the modifications; a commercial licence exists for organizations that cannot accept those terms licence terms.

Written by AI from the project's README, updated October 28, 2026. The project's own docs are the source of truth.

Hacker News

Show HN: KiviDB, a faster Redis-compatible memory database and vector cache
▲ 69 · 44 comments · October 19, 2026