Why Redis Is Fast

In one line

Redis answers in microseconds because data lives in RAM, the structures are tuned for their operations, commands run on one thread without locks, and the event loop multiplexes thousands of connections. The network round trip, not Redis, is usually the biggest cost.

0/5 · 0%

Think of it like this

A single, very fast cashier with every item within arm's reach, versus a warehouse with forklifts. The cashier never waits for a forklift (no disk), never argues with another cashier over the same item (no locks), and handles customers strictly one at a time, each in a few microseconds. The queue moves fast as long as nobody asks for something huge, like "count every item in the store".

Key ideas

01
Memory access is about 100 ns; a random read on NVMe SSD is roughly 10–100 µs; a network round trip inside one data centre is about 100–500 µs. A Redis GET spends about 1 µs executing. So from the client's view, a Redis call costs roughly one network round trip, and a well-indexed database query costs a round trip plus parsing, planning, buffer-pool lookups, locking, and possibly disk.
02
Command execution is single-threaded: one main thread runs commands one after another. There are no locks around data structures, no context switches between commands, and every single command is atomic by construction. Since Redis 6, optional I/O threads (io-threads) can read and write sockets in parallel, and background threads handle fsync, closing files and lazy freeing, but the commands themselves still execute on the main thread.
03
The event loop (ae, on epoll or kqueue) watches thousands of sockets and only touches the ones that are ready. That's how one thread serves 10,000+ connections: it never blocks waiting for a slow client.
04
The data structures are specialised: hashes and small sets use compact listpack or intset encodings that fit in CPU cache lines; sorted sets use a skiplist plus a hash table so both ZSCORE (O(1)) and ZRANK (O(log N)) are cheap. Big-O matters: GET is O(1), ZADD is O(log N), but KEYS *, SMEMBERS on a huge set or HGETALL on a huge hash are O(N) and block everyone else while they run.
05
Throughput limits: a single Redis instance typically handles 100K–1M simple ops/sec depending on CPU, payload size, pipelining and I/O threads. The ceiling is usually one CPU core plus network bandwidth, which is why hot keys and big values hurt so much (Phase 13).
06
Redis is not automatically better than a database. It's fast for key-based access on data that fits in RAM. For ad-hoc queries, joins, strong durability or datasets far larger than memory, a database wins, and a well-cached PostgreSQL query (data in shared buffers, index lookup) is often under a millisecond anyway.

Code & diagrams

event-loop.mermaiddiagram

One thread runs commands in order. I/O threads (optional) only parse and write sockets.

Rendering diagram…

benchmark.shbash

redis-benchmark ships with Redis. -P sets the pipeline depth, which shows how much of the cost is round trips.

# 100k GET/SET requests from 50 connections, no pipelining
redis-benchmark -q -n 100000 -c 50 -t get,set
SET: 118343.20 requests per second, p50=0.215 msec
GET: 121951.22 requests per second, p50=0.207 msec

# Same test, 16 commands per round trip
redis-benchmark -q -n 1000000 -c 50 -t get,set -P 16
SET: 1149425.25 requests per second, p50=0.567 msec
GET: 1388888.88 requests per second, p50=0.447 msec

# Numbers vary by machine. The ~10x jump comes from fewer round trips
# and syscalls, not from Redis executing commands faster.

latency-check.shbash

# Measure client-observed latency (sends PING in a loop)
redis-cli --latency -h 127.0.0.1
min: 0, max: 1, avg: 0.11 (4872 samples)

# Measure the latency the machine itself adds (run ON the Redis host)
redis-cli --intrinsic-latency 10
Max latency so far: 83 microseconds.
Worst run took 42x longer than the average latency.

Interview problem

The problem

Why is a Redis GET faster than a database query?

An interviewer asks: "Explain why a simple Redis GET can be much faster than a relational database query for the same row. Then explain why Redis is not automatically the better choice."

The interviewer follows up

If Redis is single-threaded, how can it serve 100K clients?

Would making Redis multi-threaded make it faster?

When it breaks

Someone runs KEYS * on a production instance with 50 million keys

What you see

The main thread spends seconds walking the keyspace. Every other client times out, health checks fail, and Sentinel or Cluster may even start a failover.

Fix & prevent

Use SCAN with a cursor and COUNT. Block KEYS for application users with ACLs (-keys or -@dangerous). Watch SLOWLOG for O(N) commands.

The app calls Redis 200 times per page load, one command at a time

What you see

Each call is fast, but 200 × 0.3 ms round trips = 60 ms per page. Redis CPU is low and the app is slow, a classic "Redis is fast but my app isn't" case.

Fix & prevent

Batch with MGET/HMGET, pipelines (Topic 3.5), or a Lua script; restructure data so one call answers one question.

Explain it without notes

Why is the network round trip, not Redis execution time, usually the main cost of a Redis call?

What are I/O threads, and why doesn't enabling them make individual commands run in parallel?

Practice

Run redis-benchmark -q -t get -n 100000 with -P 1 and then -P 32. Explain the difference in your own words.

Estimate: your app makes 40 sequential Redis calls per request with 0.4 ms RTT. What's the Redis-related latency per request, and how would you cut it?

Trade-offs

↔
Single-threaded execution gives simple atomicity and no lock overhead, but caps per-instance CPU at one core for commands; scale-out means sharding.
↔
Compact encodings (listpack, intset) save a lot of memory but make some operations O(N) within the small structure; Redis converts to full structures past a size threshold (Topic 2.3).

Done when you can

I can give approximate latencies for RAM, SSD and a data-centre round trip.
I can explain the event loop and the role of I/O and background threads.
I can explain why Redis is fast and, just as clearly, why it isn't a database replacement.
I can name at least three O(N) commands that are dangerous on big data.

Command Palette