What is Redis?

Redis (short for REmote DIctionary Server) is an in-memory data store — a database that keeps all of its data in RAM (your server’s fast memory) instead of on disk. Because RAM is thousands of times faster than a hard drive, Redis can read and write data in well under a millisecond. Most teams reach for Redis not as their main database, but as a fast helper that sits next to a slower database like PostgreSQL or MySQL and takes pressure off it. This page explains what Redis is, what it is good at, and when you should (and should not) use it, so you are ready to install it on the next page.

What kind of database is Redis?

Redis is a key-value store. The simplest way to picture it is a giant dictionary: you store a value under a unique key (a label), and later you look the value up by that key. For example, the key user:42:name might hold the value "Alice".

What makes Redis special is that the “value” can be more than just text. Redis supports several data structures (ways of organising data) out of the box:

Data type	What it holds	A real use
String	Text or numbers	A cached HTML page, a counter
Hash	A set of field-value pairs (like a row)	A user profile object
List	An ordered sequence of items	A simple job queue
Set	A collection of unique items	Tags, unique visitor IDs
Sorted Set	A set ordered by a score	Leaderboards, ranked feeds
Stream	An append-only log of events	Event pipelines, message buses

Because Redis understands these structures, your application does less work — you can push to a list or increment a counter with a single command instead of reading, changing, and writing back a whole value.

Why is Redis so fast?

Two reasons. First, all data lives in memory, so there is no slow disk lookup on every request. Second, Redis is single-threaded for command execution (it handles one command at a time on one CPU core), which avoids the locking and coordination overhead that slows many databases down. The result is that a single modest Redis server can comfortably handle 100,000+ operations per second.

What is Redis used for?

Redis is a general-purpose tool, but a handful of jobs come up again and again.

Caching

This is the number-one use. A cache is a temporary copy of data that is expensive to compute or slow to fetch. Instead of querying your main database (and running a heavy SQL join) on every page load, you store the result in Redis the first time, then serve it from memory on every later request. You attach a TTL (time-to-live, an expiry timer) so stale data clears itself automatically.

# Cache a value for 60 seconds, then read it back
redis-cli SET homepage:html "<h1>Hello</h1>" EX 60
redis-cli GET homepage:html

Output:

OK
"<h1>Hello</h1>"

Session store

When a user logs in, your app needs somewhere to remember “this person is signed in”. Storing sessions (per-user login state) in Redis means any server in your fleet can read the same session, and old sessions expire on their own via TTL.

Rate limiting

Rate limiting means capping how many requests a client may make in a window of time — for example, 100 API calls per minute. Redis makes this trivial because INCR increments a counter atomically (safely, even with many requests at once):

redis-cli INCR api:ratelimit:1.2.3.4
redis-cli EXPIRE api:ratelimit:1.2.3.4 60

Output:

(integer) 1
(integer) 1

If the counter passes your limit before the key expires, you reject the request.

Queues and background jobs

A queue is a waiting line of tasks to be processed later (sending emails, resizing images). Producers LPUSH jobs onto a Redis list and workers BRPOP them off — BRPOP blocks (waits) until a job appears, so workers don’t spin uselessly.

Pub/Sub messaging

Pub/Sub (publish/subscribe) lets one part of your system broadcast a message and many others receive it instantly — useful for live chat, notifications, or telling all servers to clear a cache.

Is Redis data ever saved to disk? (Persistence)

By default Redis lives in RAM, so a reboot or crash would wipe everything. To survive restarts, Redis offers two persistence (saving-to-disk) options that you can use alone or together.

Option	What it does	Trade-off
RDB (snapshot)	Saves a full point-in-time copy to a `.rdb` file every so often	Fast, compact; you can lose the last few minutes of writes
AOF (append-only file)	Logs every write command to disk as it happens	Far safer; the file is larger and slightly slower

On Ubuntu these files live in /var/lib/redis/ and the behaviour is set in /etc/redis/redis.conf. A balanced default looks like this:

# /etc/redis/redis.conf
save 900 1        # RDB: snapshot if >=1 key changed in 15 min
save 300 10       # snapshot if >=10 keys changed in 5 min
appendonly yes    # also keep an append-only log
appendfsync everysec   # flush the AOF to disk once per second

Gotcha: Persistence makes restarts safe, but Redis still keeps the whole dataset in RAM. If your data grows larger than available memory, Redis will start evicting keys or fail writes. Size your server’s RAM for your dataset, and set a maxmemory limit with an eviction policy (e.g. maxmemory-policy allkeys-lru) when using Redis purely as a cache.

When to use Redis — and when not to

Use Redis when…	Reach for something else when…
You need a cache in front of a slower database	You need permanent, must-never-lose records (use PostgreSQL/MySQL)
You store sessions, counters, or rate limits	Your data is far bigger than your RAM and can’t be sharded
You need a lightweight queue or pub/sub	You need complex queries, joins, or reporting (use a SQL database)
Sub-millisecond reads matter	You need full ACID transactions across many rows

In short: Redis is a brilliant complement to your main database, not usually a replacement for it.

Best practices

Always set a TTL on cache and session keys so memory frees itself; never let a cache grow forever.
Use a clear key-naming convention with colons, like user:42:profile, so keys are easy to scan and group.
Set maxmemory and an eviction policy when Redis is a cache, so it sheds old keys instead of crashing.
Enable AOF (appendonly yes) whenever losing recent writes would hurt — for pure throwaway caches you can skip it.
Never expose Redis to the public internet; bind it to 127.0.0.1 or a private network and require a password.
Prefer atomic commands (INCR, SETEX, LPUSH) over read-modify-write logic in your app to avoid race conditions.