Redis Multithreading: Why It Was Initially Single‑Threaded and What Changed in Redis 6.0

Redis is a widely used in‑memory database that, until version 6.0, handled network I/O and key‑value operations with a single thread. The design choice was driven by four main reasons: the CPU is rarely the performance bottleneck because operations are memory‑bound; a single‑threaded model simplifies development, debugging, and maintenance; it avoids the overhead of thread context switches; and I/O multiplexing (select/poll/epoll) already maximises I/O utilisation.

Although Redis’s networking and data modules are single‑threaded, other components such as persistence and cluster support have always used multiple threads. Starting with Redis 4.0, some commands were partially multithreaded, but the core network and command processing remained single‑threaded because it was deemed unnecessary.

Multithreading is beneficial when a program needs to increase CPU or I/O utilisation. For Redis, CPU utilisation is not a concern—most work is memory access—so multithreading for CPU gains offers no advantage. However, Redis is I/O‑intensive, and while multiplexing improves I/O utilisation, the underlying select/poll/epoll calls are still synchronous and can become a bottleneck under very high concurrency.

Redis 6.0 introduced a multithreaded I/O path: multiple I/O threads now parse incoming network requests, while the main thread continues to perform the actual memory reads and writes. This design removes the blocking nature of the select/poll loop, allowing better use of multi‑core CPUs and higher QPS without compromising data‑operation safety, because the data‑access path remains single‑threaded.

In summary, Redis retains a single‑threaded core for data operations to avoid concurrency complexity, but adopts multithreading for network request handling in version 6.0 to overcome the limitations of synchronous I/O multiplexing and to meet the demands of modern high‑throughput workloads.

CPU is not the bottleneck for most Redis operations.

Single‑threaded design improves maintainability and reduces context‑switch overhead.

I/O multiplexing already boosts I/O utilisation, but remains blocking.

Redis 6.0 adds multithreaded network processing to increase parallelism and QPS.