Eng | Keydb

In the world of in-memory databases, Redis has long been the gold standard for caching, real-time analytics, and message brokering. However, as applications scale, the single-threaded nature of Redis becomes a bottleneck—not due to compute, but due to I/O and context switching overhead.

KeyDB, an open-source fork of Redis, directly addresses this limitation. Maintained by Snap Inc. and now a part of the broader ecosystem, KeyDB brings multi-threaded execution to the Redis command set, offering a drop-in replacement with significant performance gains.

Operations like BLPOP or BRPOP are punted to dedicated background threads. While this prevents blocking the main pipeline, it introduces a slight latency jitter (approx. 50-100µs) for blocked commands compared to Redis.

This demonstrates how the command execution loop would handle a tiered key. keydb eng

// Inside the KeyDB command execution engine (e.g., processCommand)
void processCommand(client *c) 
    // ... standard lookup logic ...
robj *o = lookupKeyRead(c->db, c->key);
// FEATURE: Check if key is tiered (exists on disk, not in RAM)
    if (o == nullptr && isKeyTiered(c->db, c->key))
// 1. Block the client temporarily
        c->flags
// ... proceed with standard command execution ...
// Callback executed by background thread when data is ready
void onTieringFetchComplete(client *c, robj *value) 
    // 1. Restore value to the main hash table in RAM
    dbAdd(c->db, c->key, value);
// 2. Update stats (cache hits/misses)
    server.stat_tiering_loads++;
// 3. Unblock client and retry the command
    c->flags &= ~CLIENT_BLOCKED;
    handleClient(c);

partitions 8

To ensure high performance, we do not write one file per key. Instead, we use an append-only log structure similar to RDB/AOF but optimized for random reads.

Published benchmarks (KeyDB team, Snap Inc.) on a 40-core machine with memtier_benchmark: In the world of in-memory databases, Redis has

| Operation | Redis 6.0 (single-thread) | KeyDB (16 threads) | Improvement | |-----------|----------------------------|--------------------|--------------| | SET (QPS) | 450k | 4.2M | 9.3x | | GET (QPS) | 520k | 6.1M | 11.7x | | 50/50 R/W | 480k | 5.8M | 12x | | 99th %ile latency | 1.2ms | 0.6ms | 2x |

Crucially, scaling is near-linear up to ~24 cores, then allocator contention and cache coherence traffic cause diminishing returns.

A common misconception is that KeyDB is "lock-free." It is not. Instead, KeyDB uses partitioned locking (also known as hashed sharding). Each database key maps to a specific partition. A thread acquires the lock for only that partition, allowing other threads to operate on different partitions concurrently. partitions 8 To ensure high performance, we do

Redis: One command executes at a time (global mutex). KeyDB: N commands execute at a time (where N = partition count, default 4x CPU cores).

Redis’s single-threaded model uses a global lock implicitly—there is no concurrency. KeyDB introduces a fine-grained locking strategy based on key hashing.

This design allows two commands operating on keys in different shards to run truly in parallel. Commands on the same shard (or using multiple keys across shards) are serialized per shard.