Architecture: KeyDB is multi-threaded. This feature will utilize background threads to handle the I/O heavy lifting of moving data to disk, ensuring the main worker threads remain unblocked.
New Configuration Parameters:
Internal Mechanics:
KeyDB is not a silver bullet. Avoid it if: keydb eng
io-threads 6 io-threads-do-reads yes
Redis uses jemalloc, a fine-tuned allocator for multi-threaded workloads, but Redis itself is single-threaded. KeyDB operates in a truly concurrent environment, exposing allocator contention.
The most common misconception is that KeyDB simply adds threading to Redis. Redis 6.0 introduced threaded I/O (reading/writing network sockets in parallel), but the core command execution remained single-threaded. KeyDB takes the radical step of making both I/O and command execution parallel. Architecture: KeyDB is multi-threaded
Concept:
Currently, KeyDB keeps all data in RAM. While Flash storage is supported via enable-flash, this feature introduces Automatic Data Tiering. It automatically moves "cold" (infrequently accessed) keys from RAM to a secondary storage layer (SSD/Disk) while keeping "hot" keys in memory. This allows KeyDB to hold datasets much larger than the available RAM without manual intervention from the application layer.
Redis’s RDB snapshot mechanism relies on fork(). While fork() is fast (via page table copying), it causes:
KeyDB replaces fork() with checkpointing threads: Internal Mechanics:
This approach reduces memory overhead to nearly zero (only metadata copy) and eliminates the unpredictable latency of COW. The tradeoff: slightly more complex crash recovery logic if a write occurs during a checkpoint.
For over a decade, Redis has been the undisputed king of in-memory data stores. Its single-threaded architecture, while famously simple and predictable, began to show cracks in the era of multi-core NUMA machines. Enter KeyDB: a fork of Redis 5.0 that re-architects the core execution engine to exploit modern hardware. Backed by Snap, Inc. (and later open-sourced), KeyDB promises higher throughput, lower latency, and true multi-threading without sacrificing Redis protocol compatibility.
This article dissects KeyDB not as a simple "Redis with threads," but as a sophisticated system of sharded execution, optimistic locking, and memory re-engineering.