What Is Redis? The In-Memory Data Store, Explained

Redis (originally short for REmote DIctionary Server) is an open-source, in-memory data store that can serve as a cache, a primary database, and a message broker — sometimes all at once. Because it keeps data in RAM rather than writing everything to disk, it can respond to reads and writes in under a millisecond. That speed makes it one of the most widely deployed pieces of infrastructure on the internet.

How Redis works

The core idea is simple: Redis stores data as key-value pairs in memory. A key is a unique identifier; the value can be one of several data types. The simplicity of the model is what gives Redis its performance edge — there are no table scans, no query planners, and no joins. You ask for a key, you get the value, and you’re done.

Beyond plain strings, Redis supports a rich set of data structures:

Type	Example use
String	Cached HTML, session tokens, counters
Hash	User profile fields (name, email, plan)
List	Job queues, activity feeds (ordered by insertion)
Set	Unique visitors, tags (unordered, no duplicates)
Sorted Set	Leaderboards (members ordered by a numeric score)
Stream	Event logs, time-series data

Here are a few commands that show what working with Redis feels like:

# Store and retrieve a string
SET user:42:name "Chisato"
GET user:42:name          # → "Chisato"

# Give a key a time-to-live (expires in 60 seconds)
SET session:abc123 "data" EX 60

# Increment a counter atomically (great for rate limiting)
INCR api:requests:today   # → 1, 2, 3 …

# Add to a sorted set with a score (leaderboard)
ZADD game:scores 9850 "player_a"
ZADD game:scores 7200 "player_b"
ZRANGE game:scores 0 -1 WITHSCORES REV  # top scores, descending

# Publish a message to a channel
PUBLISH notifications "new_order:1234"

Note the EX 60 in the second example: any key can carry a TTL (time to live), after which Redis deletes it automatically. TTLs are the backbone of cache expiry strategies — set them on cached data and stale entries clean themselves up.

Why it’s so fast

The answer is the location of the data. Reading from RAM is orders of magnitude faster than reading from a spinning disk, and still significantly faster than reading from an SSD. Redis also uses a single-threaded event loop for command processing, which avoids the overhead of lock contention. Commands execute atomically in sequence, so you never have to worry about partial reads in most operations. (Newer versions offload network I/O to auxiliary threads, but the command loop itself stays single-threaded by design.)

What Redis is used for

Caching is the most common role. An application queries PostgreSQL or another persistent database, then stores the result in Redis with a short expiry. Subsequent requests hit Redis instead of the database, slashing response time and reducing database load.

Session storage fits naturally: sessions are small, short-lived, and accessed constantly. Storing them in Redis instead of a relational database keeps authentication fast.

Rate limiting uses Redis counters and atomic increment commands (INCR, EXPIRE) to track request counts per user or IP within a sliding window.

Task queues are built on Redis lists or the more structured Streams type. A producer pushes jobs onto a list; workers pop and process them.

Leaderboards are a textbook use case for sorted sets. Adding or updating a score is O(log N), and fetching the top-N players is instant.

Pub/sub messaging lets publishers send messages to channels that subscribers listen on in real time — useful for live notifications and chat.

Persistence: not purely volatile

Redis is in-memory, but that does not mean your data evaporates the moment the server restarts. Two persistence mechanisms exist:

• RDB (Redis Database) snapshots — Redis forks the process and writes a point-in-time snapshot of the dataset to disk at configurable intervals. Compact and fast to restore.
• AOF (Append-Only File) — every write command is appended to a log file. More durable (you can configure it to fsync on every write), but the file grows larger over time and can be compacted.

Many production deployments use both: RDB for fast restarts and AOF for durability between snapshots.

Memory limits and eviction

RAM is finite, so Redis lets you cap memory with maxmemory and choose an eviction policy for when the cap is hit. The two mindsets matter more than the exact settings:

• Cache mindset — use allkeys-lru (evict the least-recently-used keys) or allkeys-lfu (least-frequently-used). Losing a key is fine; the source of truth lives elsewhere.
• Store mindset — use noeviction, which rejects writes when memory is full instead of silently dropping data.

Mixing the two mindsets in one instance is a classic operational mistake: a growing cache can evict data you meant to keep. Run separate instances, or be deliberate about which policy you’re under.

Scaling beyond one server

A single Redis instance goes remarkably far, but three mechanisms extend it: replication (replicas serve reads and stand by for failover), Sentinel (monitors the primary and promotes a replica automatically if it dies), and Redis Cluster (shards the keyspace across multiple nodes for datasets too big for one machine’s RAM). Most applications never need Cluster — a primary with one replica covers a lot of production reality.

One ecosystem note: after Redis changed its license in 2024, the Linux Foundation launched Valkey, an open-source fork that is drop-in compatible for most workloads and now ships as the default “Redis” option in several clouds and package managers. Whichever you deploy, the concepts in this article apply equally.

When to use Redis

Reach for Redis when you need sub-millisecond access to frequently read data, when your access pattern is key-based rather than query-based, or when you need lightweight message-passing between services. It pairs naturally alongside a relational database like PostgreSQL rather than replacing it — Redis handles the hot data, while Postgres owns the source of truth. If your caching needs are dead simple and throughput is everything, it’s worth reading Redis vs Memcached before defaulting to Redis.

If your use case involves storing and querying unstructured or geographic data at scale, it is also worth looking at what edge databases offer, or exploring vector databases if you are building semantic search or AI-backed features.

Common questions

Is Redis a database or a cache?

Both, depending on configuration. With persistence enabled and noeviction set, it’s a legitimate primary database for the right workloads. Configured with an LRU eviction policy and TTLs, it’s a cache. The software is the same; the operational contract is different.

Does Redis lose data on restart?

Not if persistence is configured. RDB snapshots and the AOF log both survive restarts; you can lose at most the writes since the last snapshot or fsync, which is tunable down to zero (at a throughput cost).

What does Redis stand for?

REmote DIctionary Server. It was created in 2009 by Salvatore Sanfilippo, who built it to speed up a web analytics product.

When should you not use Redis?

When your data exceeds what RAM can economically hold, when you need complex ad-hoc queries and joins, or when strong relational guarantees matter more than latency. Those are jobs for a disk-based database — keep Redis in front of it, not instead of it.

The takeaway

Redis is fast because it works in memory, and useful because it does more than just caching. Its data structures map cleanly onto common problems — queues, leaderboards, sessions, rate limits — and its persistence options make it reliable enough for many production workloads. If you find yourself reaching for a separate caching layer, a session store, or a simple message queue, Redis is almost certainly the right tool to evaluate first — and if you want to understand it from the inside, try building your own Redis.