KiviDB: A Rust-based Redis alternative with built-in vector search

A new open-source project called KiviDB has emerged as a high-performance alternative to Redis and Valkey, written in Rust. Released in October 2026, it targets infrastructure engineers seeking drop-in compatibility with existing Redis clients while adding native support for full-text and vector search. The project claims significant throughput improvements over established engines by leveraging a sharded, multi-core architecture.

What happened

KiviDB is designed to speak the Redis protocol, supporting both RESP2 and RESP3 standards. This compatibility means that existing tools like redis-cli, as well as popular client libraries, can connect to KiviDB without modification. Unlike traditional Redis instances that often rely on single-threaded execution for core commands, KiviDB distributes work across every available CPU core using a sharded in-memory design. It also includes persistence mechanisms via snapshots and an optional append-only file.

The project distinguishes itself by bundling search capabilities directly into the core engine. Users can execute Redis Stack-style FT.* commands for full-text, tag, numeric, and vector searches without installing separate modules. In benchmarks conducted on AWS Graviton3 bare metal instances, KiviDB demonstrated substantial performance gains. On a 32-core setup, it served 21 million pipelined GET operations per second, which the developers state is approximately nine times faster than Redis 8 and 2.3 times faster than Dragonfly.

Latency metrics also favored the new engine, with p99 latency reported at less than half that of Dragonfly in pipelined scenarios. However, in non-pipelined tests, Dragonfly maintained a slight edge in raw operations per second. These results highlight how workload patterns, such as pipelining, significantly influence the relative performance of these in-memory stores. The benchmarks were performed in a controlled environment, and the authors advise testing on specific hardware before production adoption.

How it works

KiviDB achieves its concurrency by running commands on every core through a sharded architecture. This approach contrasts with the single-threaded model of standard Redis or the shared-nothing model of Dragonfly. By distributing keys across shards, the system allows parallel processing of requests, reducing contention on any single thread. The engine is written in Rust, utilizing the 2024 edition of the language, and relies on a stable toolchain starting from Rust 1.89.

For vector search, KiviDB implements approximate nearest neighbor algorithms, specifically supporting FLAT and HNSW indexes. Vectors are stored as raw FLOAT32 little-endian bytes within hash fields, adhering to the same convention used by Redis Stack. When a search query is executed, the engine uses these indexes to find similar vectors efficiently. The system persists not just the key-value data but also the index schemas and HNSW graphs, ensuring that search quality remains consistent after restarts without requiring a full rebuild.

The software offers flexibility through Cargo features, allowing users to build variants with or without Lua scripting and TLS support. By default, it runs without these features to minimize dependencies and attack surface. On Linux systems, it attempts to use io_uring for asynchronous I/O if the kernel permits, falling back to Tokio otherwise. This low-level I/O handling contributes to its ability to manage high connection counts and throughput efficiently.

Key details

• Protocol Compatibility: Supports RESP2 and RESP3, allowing existing Redis clients and tools to connect without changes.
• Performance Claims: Benchmarks show 21 million pipelined GETs per second on 32 cores, outperforming Redis 8 and Dragonfly in specific scenarios.
• Built-in Search: Includes native support for full-text, tag, numeric, and vector search using FT.* commands, eliminating the need for external modules.
• Multi-threaded Architecture: Utilizes all CPU cores via a sharded in-memory design, differing from the single-threaded nature of standard Redis.
• Persistence Options: Supports snapshots (dump.kdb) and an optional append-only file (AOF) for data durability.
• Licensing: Released under the GNU Affero General Public License v3 (AGPL-3.0-only), which may impact usage in proprietary software distributions.

Why it matters

For software engineers building AI-driven applications, the integration of vector search directly into the cache layer simplifies infrastructure. Traditionally, teams had to manage separate services for caching and vector similarity search, leading to increased operational complexity and potential consistency issues. KiviDB’s approach allows developers to use a single interface for both fast key-value lookups and semantic search, potentially reducing the number of moving parts in their stack.

The performance improvements reported in multi-core environments address a common bottleneck in high-throughput systems. As applications scale, the single-threaded limitation of traditional Redis can become a constraint, forcing teams to shard manually or adopt more complex clustering solutions. KiviDB’s automatic sharding across cores offers a path to higher utilization of modern multi-core servers without requiring application-level changes to handle sharding logic.

However, the choice of license is a critical consideration for technical leads. The AGPL-3.0 license requires that if you modify the software and provide it over a network, you must make the source code available. While using KiviDB as a service does not necessarily force your application code to be open source, legal review is essential for organizations with strict proprietary requirements. This contrasts with alternatives like Valkey, which uses a BSD-3-Clause license, offering more permissive terms for commercial use.

What you can do

• Test KiviDB locally using Docker by running docker run -d -p 6380:6380 kividb/kividb and connecting with redis-cli -p 6380.
• Benchmark your specific workload against KiviDB, Redis, and Dragonfly to determine if the multi-threaded architecture provides tangible benefits for your use case.
• Review the AGPL-3.0 license implications with your legal team if you plan to use KiviDB in a commercial product or distributed service.
• Experiment with the built-in vector search capabilities by creating indexes with FT.CREATE and querying them with FT.SEARCH to evaluate search quality and latency.
• Configure persistence by enabling the append-only file (--aof) flag in Docker or command-line arguments to ensure data durability across restarts.
• Monitor memory usage, as KiviDB’s memory per key was reported at 177 bytes in benchmarks, which is slightly higher than Dragonfly’s 134 bytes but comparable to Redis.