KiviDB claims to be up to 9 times faster than Redis while keeping full compatibility
KiviDB is an in-memory database written in Rust that speaks the Redis protocol, adds native vector search, and publishes its own benchmarks against Redis, Dragonfly, and KeyDB. The numbers show a real gain in pure caching, but the story is more contested in vector search.
KiviDB is an in-memory database written in Rust that speaks the Redis protocol, adds native vector search, and publishes its own benchmarks against Redis, Dragonfly, and KeyDB. The numbers show a real gain in pure caching, but the story is more contested in vector search.
What KiviDB is
KiviDB is an in-memory database written in Rust that positions itself as an alternative to Redis and Valkey. It speaks the RESP2 and RESP3 protocols, so Redis clients, redis-cli, and existing libraries work without changes. The project appeared in a Show HN on GitHub, with the README documenting benchmarks, build variants, and vector search commands compatible with Redis Stack.
The core architectural difference is how each command is processed. Redis runs on a single thread with I/O handled by auxiliary threads; KiviDB distributes commands across all cores, in a sharded design. Dragonfly is also shared-nothing across cores, and it is the closest competitor in the published numbers.
The server listens by default on port 6380, not Redis's 6379, which allows running both side by side during a migration:
docker run -d -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING # PONGThe benchmark numbers
The tests, described as having been run in October 2026 on bare-metal AWS Graviton3 instances (a c7gn.metal with 64 vCPUs limited to 32 cores), used memtier_benchmark with 10 million keys and 100-byte values. With a pipeline of 16 commands, KiviDB 1.1.0 delivered 21.2 million GETs per second, versus 9.1 million for Dragonfly 2.0.2 and 2.4 million for Redis 8.10 (4.7 million on Redis Cluster with 32 shards).
Tail latency followed the same pattern: p99 of 0.36 ms for GET and 0.42 ms for SET on KiviDB, versus 0.88 ms and 1.07 ms on Dragonfly, and 2.2 ms and 2.7 ms on Redis 8.10. Without pipelining, though, the picture changes: Dragonfly reaches 3.35 million GETs per second against 3.07 million for KiviDB, a small difference in favor of the competitor. Memory usage per key came out to 177 bytes on KiviDB, close to Redis's 178 bytes and KeyDB's 183 bytes, but above Dragonfly's 134 bytes.
In short: KiviDB's throughput gain is real and significant in scenarios with aggressive pipelining, which is how most cache clients actually operate in production, but it does not win in every scenario, nor is it the most memory-efficient.
Vector search: where the advantage gets more contested
KiviDB implements FT.* commands in the Redis Stack style, including HNSW and FLAT indexes over hash fields, with the same little-endian FLOAT32 blob format used by redis-py and NumPy. In practice, anyone already using FT.CREATE and FT.SEARCH with Redis Stack can migrate the index without rewriting the application:
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 128The vector search benchmark, run with redis/vector-db-benchmark on the glove-25-angular dataset (1.18 million vectors, 25 dimensions, HNSW with M=16 and EF_CONSTRUCTION=256), shows a more balanced picture than pure caching. At ef 64, KiviDB processes 59,300 queries per second with a recall of 0.943, ahead of Dragonfly (41,300) and Redis 8.10 (31,800). At ef 512, however, Dragonfly takes the lead in throughput, with 29,800 queries per second against 18,700 for KiviDB, but it is KiviDB that keeps the higher recall (0.998 versus Dragonfly's 0.995).
Ingestion and index-build time also weighs against KiviDB: 31 seconds, more than double Dragonfly's 13 seconds, though less than Redis 8.10's 38 seconds. After ingestion, KiviDB uses 1.66 GB of memory versus 1.13 GB for Dragonfly and 1.07 GB for Redis. For anyone building a RAG pipeline with millions of vectors, this memory and indexing-time cost matters just as much as query latency.
What changes in practice for those running cache and vector search
For teams in Brazil running session cache, rate-limit queues, or feature stores on Redis, KiviDB's direct appeal is reducing the number of instances without changing application code. If the project's own numbers hold up under real workloads, a single KiviDB running on 32 cores would replace several Redis Cluster replicas just to sustain read throughput, which has a direct effect on the cloud infrastructure bill.
Protocol compatibility lowers migration risk: the README states that redis-cli and the integration tests (in tests/e2e/) use safe binary commands, the same as any standard Redis client. This means that switching engines is, in theory, a change of endpoint and port, not of library or query.
Two operational points deserve attention before any adoption:
- Protected mode by default outside a container: as with Redis, KiviDB only accepts local connections without a password until you set
--requirepass,--bind, or turn offprotected-mode. This is relevant in Brazil, where leaks from misconfigured Redis instances exposed without a password have already caused known security incidents. - The Docker image flips that default: since it always runs over the network, the container starts with
--protected-mode noby default, and any custom flag you pass overrides that behavior, potentially re-enabling protection without warning. It is worth reviewing the documentation before publishing a container to production.
License and build: what to check before adopting
KiviDB is distributed under AGPL-3.0, the same license adopted by current Redis; Valkey, in turn, offers options under RSALv2, SSPLv1, or AGPL-3.0. According to the project itself, an application that connects to KiviDB over the network, through any Redis client, is a separate program and does not inherit AGPL obligations. The license obligation only kicks in if someone modifies KiviDB itself and offers that modified version as a network service to third parties, in which case the modification's code must be made open.
For those who cannot use AGPL or want to embed KiviDB without publishing changes, the company behind the project, KIVIDB PRIVATE LIMITED, offers a separate commercial license. It is the same dual-licensing model that other Rust and C++ databases have been adopting in recent years to sustain development without giving up open source.
The binary has four build variants via Cargo features: the default (without Lua or TLS), lua (adds EVAL, SCRIPT, FUNCTION, and FCALL), tls, and full (both combined). Lua scripting and TLS are not enabled by default, so teams that currently rely on scripting in Redis need to explicitly build or download the variant with --features lua before migrating.
What remains open
The published numbers come from KiviDB's own repository, run in a single session in October 2026 on specific AWS hardware (Graviton3), and the project itself warns that results depend on the environment and recommends measuring against the real workload before trusting them. So far, there is no independent third-party benchmark replicating these numbers, nor any public reports of production use at scale.
It is also unclear from the available material how KiviDB behaves in multi-node cluster scenarios under failure, since the throughput numbers were measured with the server alone, with no replicas or failover enabled during the test. For anyone considering switching engines, the project's own recommendation is to run kivi-benchmark (documented in benchmarks/LATEST.md) against the application's real workload before making any decision.
Source
Translated from the Brazilian Portuguese original · Read the original
PS5LM runs GGUF models via llama.cpp inside a jailbroken PS5
An open-source project gets llama.cpp running on the console's GPU and exposes the loaded model through an API compatible with OpenAI and Anthropic, accessible to any device on the local network.
