Memory is only the first answer
Everybody's first answer is that it keeps data in memory, and that is the biggest factor. A memory access costs around 100 nanoseconds where reading a disk costs around 100 microseconds, a thousand times more.
Plenty of software touches memory and is still slow, so the rest of the answer lives in how it executes.
Run commands on a single thread, as Redis does. No locks, no contention, no switching between workers fighting over the same table, and every operation is atomic by construction, because nothing else can run in the middle of it.
See what that hands you free: an increment is a safe concurrent counter with no synchronisation code at all, in the server or in your application.
Recent versions do use extra threads for network work and background tasks, and command execution stays serialised, because the simplicity is the point.
Get your concurrency from watching sockets instead. The event loop watches thousands of client connections and processes whichever have data ready, one command at a time, each finishing in microseconds.
Understand why that works. Waiting on the network is the slow part, and Redis never waits, because it works on somebody else's request while yours is in flight.
Expect the practical numbers: around a hundred thousand operations a second on one instance, latency under a millisecond, and past a million a second when you batch many commands into one round trip.
The knife in the model
Respect the knife hidden in this model. One thread means one slow command blocks every client.
Watch which commands can do that. Listing every key on a database of ten million, reading a giant set, or a careless script freezes the whole instance until it finishes. That is why production installations ban the listing command in favour of an incremental scan, and why latency spikes on a shared instance are usually one team's expensive command rather than the network.
Worked example
Farhan's team sees their shared Redis latency at p99, the slowest one request in a hundred, jump from 1 ms to 800 ms every few minutes, and the network team finds nothing. He runs SLOWLOG GET and the culprit is right there: a coworker's cleanup job calling KEYS session:*, which scans all 12 million keys in about 700 ms while every other client waits, since command execution is single-threaded. During each scan, roughly 40,000 requests from the checkout service queue behind it. The fix takes an hour: the job switches to SCAN with a COUNT of 1,000, iterating in small slices between other commands, and the cleanup takes slightly longer overall while the p99 returns to 1 ms. Farhan then sets a latency alert keyed to slowlog entries, because the next expensive command is always one deploy away.