Redis is fast because of what it removed, not because of a clever algorithm. Three things make ordinary databases slow, and Redis took all three off the hot path.

It never reads from disk to answer you

The entire dataset lives in memory. Persistence happens, but it happens alongside command execution rather than in front of it. A read is a pointer dereference, not a page fetch — that is roughly five orders of magnitude, and it dwarfs every other optimisation in the system.1

One thread, so no locks

Command execution is single-threaded. That sounds like a limitation and is actually the main source of speed: no mutexes, no lock contention, no context switching between worker threads, no cache-line ping-pong between cores. Commands run to completion one at a time on an event loop, which is also why every individual Redis command is atomic without you asking for it.

The cost is that one slow command blocks everything behind it. KEYS * on a large database is not merely slow — it is a stall for every other client connected. This is the single most important operational fact about Redis.1

Networking and I/O were made multi-threaded in 4.0 and 6.0, but the part that touches your data was deliberately left alone.

Data structures that change shape

A small hash is stored as a flat array of field-value pairs, which is compact and cache-friendly. Past a configured threshold it converts itself into a real hash table. Small sorted sets use a listpack; large ones use a skiplist.

You get the memory profile of the small representation and the complexity guarantees of the large one, without choosing. Most of the “why is my Redis using so much memory” surprises trace back to a collection quietly crossing one of those thresholds.

What that buys, and what it costs

The consequence of all this is a latency profile that is not just low but predictable — which is usually what you actually want from a cache. The costs are the other side of the same design: your data must fit in RAM, one slow command stalls everyone, and durability is a spectrum you configure rather than a guarantee you get. Fork-based snapshotting in particular can double memory usage under heavy writes, which is the classic 3am Redis incident.1