What Is Redis? Why It Is Fast and What You Trade for It

What Redis Actually Is

At its simplest Redis is a key-value store: you give it a name, it gives you back what you saved under that name. But it also understands structured types — lists, sets, sorted sets, hashes, streams — which is what separates it from a plain cache and makes it useful for things like leaderboards, queues and rate limiters.

It is single-threaded for command execution, which sounds like a limitation and mostly is not. Because every operation completes in microseconds, one thread handles enormous throughput, and the design removes an entire class of concurrency bugs. It also means one slow command blocks everything behind it, which is worth remembering before you run an operation across every key.

Why It Is Fast, and What You Trade Away

Disk is slow compared with memory — that gap is the whole story. By keeping the working set in RAM, Redis skips the slowest part of what a normal database does.

The trade is that RAM is volatile and expensive. Volatile means data disappears when the process stops, unless you configure persistence. Expensive means you cannot store much of it: a server with 8 GB of RAM stores 8 GB of data, where the same money buys hundreds of gigabytes of disk.

Redis does offer persistence — periodic snapshots, or an append-only log of every write. Both help, and neither makes Redis a safe system of record. Snapshots lose everything since the last one, and even the append-only log can lose the last second of writes in the default configuration. That is entirely acceptable for a cache and entirely unacceptable for orders or payments.

What Redis Is Genuinely Good For

Redis Is Not Your Main Database

This needs saying plainly because people do try. Redis can persist to disk, which makes it look like a viable primary store, and there are cases where it is used that way deliberately by people who understand exactly what they are accepting.

For everyone else it is the wrong choice for three reasons. Your entire dataset must fit in RAM, which puts a hard and expensive ceiling on growth. Durability is best-effort rather than guaranteed, so a crash can lose recent writes. And there is no rich query language — you can fetch by key, but you cannot ask "every order from last month over ฿5,000" without building and maintaining that index yourself.

The normal architecture is boring and correct: PostgreSQL or MySQL holds the truth, Redis holds a fast copy of the parts you read constantly. If Redis vanishes entirely, the site gets slower and keeps working. That is the property you are designing for.

Redis vs Memcached

Memcached is the other well-known in-memory cache, and the comparison comes up whenever someone is choosing one.

Will Adding Redis Actually Make Your Site Faster?

Sometimes dramatically, sometimes not at all, and it is worth knowing which before you install anything.

Redis helps when the same expensive work is repeated. A homepage that runs twelve database queries for every visitor, an API that recomputes the same aggregate constantly, a session store hit on every single request — these get faster immediately and noticeably.

Redis does not help when the work is genuinely different each time, when your database is already fast enough, or when the real bottleneck is somewhere else entirely. Adding a cache to a site whose slowness comes from unoptimised images or blocking JavaScript changes nothing, and you have added a service to maintain for no benefit.

The honest sequence is: measure first, find where the time actually goes, and add Redis if the answer is "repeated database work". Installing a cache and hoping is how people end up with a more complicated stack and the same load time.

How Much RAM to Budget

Redis needs memory for the data itself plus overhead, and it must share the machine with everything else running there.

The Security Mistake That Costs People Their Servers

Redis historically shipped with no password and, in older versions, listening on all network interfaces. That combination — an open port with no authentication — is one of the most reliably exploited misconfigurations on the internet.

What happens is not subtle. Automated scanners find open Redis ports within hours. An attacker with write access to Redis can often write files to disk, add an SSH key, and own the machine outright. Cryptocurrency miners installed this way are a standard outcome, and the first sign is usually a CPU that never drops below 100%.

The protection is short and non-negotiable: bind Redis to 127.0.0.1 so it is unreachable from outside, set a long password with requirepass, keep protected-mode enabled, and never open port 6379 in the firewall. If an application on another server genuinely needs access, tunnel it over SSH or a private network rather than exposing the port.

It is also worth renaming or disabling the dangerous commands — FLUSHALL, CONFIG and KEYS — in production. The first two let an intruder wipe or reconfigure everything, and the third can freeze a busy instance for seconds at a time even when a well-meaning developer runs it.