Redis Introduction

What Redis is#

Redis (REmote DIctionary Server) is an in-memory data structure store, used as a database, cache, message broker, and more. Unlike MySQL or PostgreSQL, where data lives primarily on disk and is cached in memory opportunistically, Redis keeps its entire dataset in RAM by default — disk is used only for optional persistence (snapshotting or an append-only log), not as the primary read/write path.

Redis isn't a relational or document database competing on the same ground as the others in this track — it's usually deployed alongside a primary database, handling the subset of data where raw speed matters more than rich querying: caching, sessions, rate limiting, real-time counters, leaderboards, and pub/sub messaging.

Why Redis is so fast#

Two design decisions account for most of Redis's speed:

• Everything lives in memory. RAM access is orders of magnitude faster than disk I/O, even fast SSDs — reading a value from Redis typically takes well under a millisecond, versus milliseconds-to-tens-of-milliseconds for an equivalent disk-backed database query under load.
• Simple, purpose-built data structures. Redis doesn't parse SQL, plan query execution, or maintain a general-purpose relational engine — each data type (covered on the next page) has a small set of operations implemented as direct, highly optimized in-memory operations on that structure. A GET is a hash table lookup; an LPUSH is a linked-list insertion. There's no query planner deciding how to execute it.

Redis also runs its core command processing on a single thread (per instance), which sounds like it should be slower, not faster — but it sidesteps the locking overhead multi-threaded systems need to coordinate concurrent access to shared data structures, and in practice a single Redis thread handles hundreds of thousands of simple operations per second, far beyond what most applications ever need from a single instance.

Installing and connecting#

On Ubuntu/Debian:

sudo apt install redis-server
sudo systemctl start redis-server

Connect with redis-cli, Redis's command-line client:

redis-cli

127.0.0.1:6379> PING
PONG
127.0.0.1:6379> SET greeting "hello"
OK
127.0.0.1:6379> GET greeting
"hello"

PING is the standard way to confirm the server is up and reachable — it's also what most Redis client libraries and health checks use internally.

Common use cases#

• Caching — storing the result of an expensive database query or computation with a time-to-live, covered in depth on the caching-patterns page in this section.
• Session storage — web sessions are small, frequently read/written, and don't need to survive forever, a natural fit for an in-memory store.
• Rate limiting — atomic increment operations (INCR) with a TTL make a clean building block for "no more than N requests per window."
• Leaderboards and real-time rankings — sorted sets (covered on the next page) keep a scored, ordered list updated in real time.
• Pub/sub messaging and lightweight queues — covered on the pub-sub-and-streams page.

Common mistakes#

• Treating Redis as a replacement for a primary database rather than a complement to one — Redis has no relational querying, limited (though real) durability guarantees compared to a disk-first database, and is typically sized to fit the working set in RAM, which isn't practical for a full application dataset.
• Forgetting that data in Redis is volatile by default unless persistence (RDB snapshots or AOF logging) is explicitly configured — a restart without persistence enabled loses everything in memory.
• Storing large, complex objects as a single serialized blob when Redis's native data structures (hashes, sets, sorted sets) would let you read or update individual fields without deserializing and re-serializing the whole thing.