What Is Redis? A Complete Guide to the In-Memory Data Store

Last reviewed: August 2026. Verified against Redis 8.10.

Redis is an in-memory data structure store used as a cache, database, message broker, and vector search engine. It keeps the working set in RAM rather than on disk, which is why operations complete in microseconds instead of milliseconds, and it exposes purpose-built data structures such as sorted sets and streams rather than a single opaque value type.

That combination has made it one of the most widely deployed pieces of infrastructure in the world. It has also made it the source of more confusion than usual over the past two years, because Redis changed its license twice, got forked, absorbed its own module ecosystem, and rebranded, all between 2024 and 2025.

This guide covers what Redis is, what it's good at, where it struggles, and what the current state of the project actually is.

What Redis is, precisely

Redis stores key-value pairs where the value is a typed data structure rather than a blob. That's the design decision everything else follows from.

You don't fetch a serialized list, modify it in your application, and write it back. You run LPUSH and the server handles it atomically. You don't compute a leaderboard, you run ZINCRBY and ZREVRANGE. Operations execute on the server, next to the data, on a single thread that guarantees they don't interleave.

Core data structures:

• Strings hold text, numbers, or binary data up to 512 MB, with atomic increment and append operations
• Hashes map fields to values, useful for objects, and support per-field TTLs since Redis 7.4
• Lists are linked lists supporting push and pop from either end, which makes them queues or stacks
• Sets hold unique unordered members with union, intersection, and difference operations
• Sorted sets hold unique members each with a score, kept ordered, which is what makes leaderboards and priority queues trivial
• Streams are append-only logs with consumer groups, added in Redis 5.0
• Bitmaps, HyperLogLog, and geospatial indexes handle presence tracking, cardinality estimation, and location queries

Since Redis 8.0, the core distribution also includes JSON, time series, five probabilistic structures, vector sets, and a query engine. More on that below, because it's a significant change from how Redis worked for its first fifteen years.

A short history, told accurately

Salvatore Sanfilippo built Redis in 2009 while working on LLOOGG, a real-time web analytics product he had founded. The problem was that his existing database could not keep up with the write load, so he wrote a prototype in C.

This is worth stating carefully because it's frequently reported wrong, including in an earlier version of this guide, which said he built Redis at VMware. He did not. VMware hired him in March 2010, roughly a year after Redis existed, and sponsored his work on it from there. Sanfilippo stepped away from the project in 2020 and returned to Redis in December 2024.

The company behind Redis has also been renamed twice: Redis Labs became Redis Ltd. in 2021, and now brands simply as Redis. Content still referring to "Redis Labs" is at least five years out of date, which is a useful signal when you're evaluating a source.

The major releases, briefly:

Is Redis open source?

Yes, as of Redis 8.0 in May 2025. Redis is tri-licensed under RSALv2, SSPLv1, or AGPLv3, and AGPLv3 is OSI-approved.

The confusion is understandable, because this changed twice in fourteen months.

In March 2024, Redis Ltd. moved the core from BSD to a dual source-available license, aiming at cloud providers offering Redis as a managed service without contributing back. Eight days later the Linux Foundation forked Redis 7.2.4, the last BSD release, as Valkey, with backing from AWS, Google, Oracle, and Ericsson.

In May 2025, Redis 8.0 added AGPLv3 as a third option, citing that the forks had achieved a level playing field. Redis was open source again.

What AGPLv3 obliges you to do is narrower than most people assume. Modify Redis and expose the modified version over a network, and you must offer the source of your modifications. Run unmodified Redis behind your application and nothing is triggered. It does not reach your application code.

The practical blockers are elsewhere: some legal teams have blanket AGPL policies, and it makes closed-source redistribution of a modified engine impractical. That's why the cloud providers stayed on Valkey after the AGPL pivot rather than switching back. If licensing is your deciding factor, the Valkey vs Redis comparison covers it in more depth.

What Redis is used for

Caching is the dominant use. Put Redis between your application and a slower database, serve repeat reads from memory. The SET key value EX 300 pattern handles most of it. Expect to think about eviction policy, cache invalidation, and what happens on a cold start.

Session storage. Sessions are small, hot, and naturally expiring, which fits Redis exactly. Every major web framework has an adapter.

Rate limiting. Atomic INCR plus EXPIRE gives you a counter that cannot race. Sliding windows with sorted sets when fixed windows aren't good enough.

Job queues. Lists with BRPOPLPUSH for reliable handoff, or Streams with consumer groups when you need acknowledgments and replay. Sidekiq, Celery, BullMQ, and Resque are all built on this.

Leaderboards and ranking. Sorted sets do this in one data structure, with O(log N) inserts and O(log N + M) range queries. Hard to beat.

Real-time analytics. Counters, HyperLogLog for approximate unique counts at fixed memory cost, bitmaps for daily-active tracking.

Pub/sub and messaging. Lightweight fan-out with no delivery guarantee. If you need durability, use Streams instead. This distinction catches people out.

Vector search and semantic caching. Newer, and the reason Redis 8 exists in the shape it does. Vector Sets and the Query Engine support similarity search for retrieval-augmented generation, and semantic caching of LLM responses has become a common pattern.

What changed in Redis 8

Redis 8.0, released May 2025, is the largest change to the project in a decade, and a lot of writing about Redis still describes the world before it.

Redis Stack is gone, absorbed into the core. RediSearch, RedisJSON, RedisTimeSeries, and RedisBloom used to be separately installed modules. They now ship in the standard distribution. Installing Redis gets you:

• The Query Engine, with horizontal and vertical scaling for search, query, and vector workloads
• JSON as a native type
• Time series
• Five probabilistic structures: Bloom filter, Cuckoo filter, Count-min sketch, Top-K, t-digest
• Vector Sets, a structure Sanfilippo designed for similarity search

Community Edition became Redis Open Source. A naming change, but it appears in documentation and package names.

Performance. Redis reports up to 87% lower command latency and roughly double the throughput versus 7.4, from I/O threading and over thirty targeted optimizations. Treat vendor benchmarks as vendor benchmarks, but the I/O threading gains on connection-heavy workloads are real.

A caution on ACLs. The module integration changed ACL rules in ways that can break existing configurations. Worth testing before you upgrade rather than after.

Since 8.0, the line has moved quickly: 8.4 in November 2025, 8.6 in February 2026, and 8.10 in July 2026. Recent additions include batched prefetch for MGET, MSET, and HGETALL, a compact hash encoding that stores field names once across keys sharing a schema, HIMPORT for bulk hash insertion, and a node-side BACKUP command built on multi-part AOF.

Redis 8.0 reaches end of support on 1 December 2026. Anything on 7.0 or earlier is already past EOL and receiving no security patches. The July 2026 coordinated security release patched every supported line from 6.2 through 8.8, which gives you a sense of the cadence.

Getting started

Docker is the fastest route:

docker run -d --name redis -p 6379:6379 redis:8.10
docker exec -it redis redis-cli

Package managers:

# Debian / Ubuntu
sudo apt install redis-server

# macOS
brew install redis

Distribution packages often lag well behind. Ubuntu and Debian repositories have historically shipped versions several major releases old, so check what you actually got:

redis-cli INFO server | grep redis_version

If it's below 8.0, you're missing the integrated modules and a lot of performance work. Redis maintains its own APT and RPM repositories for current builds.

A few commands to get oriented:

SET user:1001:name "Ada"
GET user:1001:name

HSET user:1001 name "Ada" email "ada@example.com" role "admin"
HGETALL user:1001

LPUSH jobs "send-email"
BRPOP jobs 0

ZADD leaderboard 5000 "alice" 7500 "bob"
ZREVRANGE leaderboard 0 9 WITHSCORES

SET session:abc "payload" EX 3600

The objectType:id:field key convention is worth adopting from the start. Redis has no namespaces, so key naming is your only organizational structure, and retrofitting it is miserable.

Persistence: RDB and AOF

Redis is in-memory, but it can persist to disk two ways.

RDB takes point-in-time snapshots by forking and writing a compact dump. Fast to load, small on disk, and you lose everything written since the last snapshot if the process dies.

The defaults are frequently misreported. The actual redis.conf defaults are:

save 900 1
save 300 10
save 60 10000

Read as: snapshot after 900 seconds if at least 1 key changed, after 300 seconds if at least 10 changed, after 60 seconds if at least 10000 changed. Not "every 5 minutes if one key changed," which an earlier version of this guide claimed.

The fork is the operationally important part. It triggers copy-on-write memory allocation proportional to your write rate during the snapshot, which is the most common reason a memory-constrained Redis gets OOM-killed. Leave headroom.

AOF logs every write and replays it at startup. More durable, larger files, slower cold start.

appendonly yes
appendfsync everysec

everysec is the standard compromise: at most one second of writes lost on an unclean stop, without the throughput cost of always. Redis 8 added auto-repair for a broken AOF tail on startup, which removes one of the more annoying failure modes.

Running both is normal. AOF for durability, RDB for fast restores and backups.

Replication, Sentinel, and Cluster

Replication is asynchronous primary-replica. Replicas serve reads and act as failover candidates. Set it up with REPLICAOF <host> <port>.

Asynchronous means a primary can acknowledge a write and die before the replica has it. WAIT gives you a partial answer by blocking until N replicas acknowledge, but it is not a consensus protocol and does not make Redis strongly consistent. Design around that rather than around a hope.

Sentinel monitors primaries and promotes a replica when one fails. It needs its own quorum, typically three Sentinel processes on separate hosts. It handles failover, not scaling.

Redis Cluster shards the keyspace across nodes. The keyspace is divided into 16384 fixed hash slots, distributed across your primary shards. The slot count is constant and unrelated to node count. A valid cluster needs three primaries minimum, each ideally with a replica.

Cluster mode has real constraints. Multi-key operations only work when the keys land in the same slot, which means using hash tags like {user:1001}:profile to force colocation. Transactions and Lua scripts inherit the same restriction. Resharding is an online operation, but it produces MOVED and ASK redirects that clients have to handle, and under load those can surface as timeouts.

Most teams that end up on Cluster get there because a single Redis process ran out of CPU, not because it ran out of memory. Which brings us to the constraint underneath all of this.

The single-thread constraint

Redis executes commands on one thread. This is a deliberate design choice and it buys real things: atomic operations with no locking, predictable latency, and a codebase that is genuinely comprehensible.

It also means a Redis process uses roughly one CPU core for command execution regardless of how many the machine has. On a 32-core server, Redis leaves most of them idle.

Redis 8's I/O threading moves socket reads and writes onto additional threads, which helps meaningfully on workloads with many concurrent connections. Command execution is still serialized. The ceiling moved; it did not disappear.

The consequence is that scaling Redis past one core means running more Redis processes, which means Cluster, which means slot management, resharding runbooks, hash tags, and a topology whose operational complexity grows with your data.

That's a reasonable trade at moderate scale. It gets expensive at large scale, and the expense is mostly operational rather than infrastructural.

Where Redis is the wrong tool

As a primary datastore for durable data. Persistence exists, but asynchronous replication and fork-based snapshots mean the durability guarantees are weaker than a database designed for it. People do run Redis as a system of record. They usually regret the first hard failure.

For complex queries. The Query Engine in Redis 8 is a real improvement, but this is not a relational database. No joins, no ad-hoc analytical queries.

For large cold datasets. Everything lives in RAM, so cost scales with total dataset size rather than working set size. If 90% of your data is rarely touched, you're paying full memory price for all of it. Redis Enterprise offers data tiering; open source Redis does not.

For guaranteed message delivery. Pub/sub is fire-and-forget. Streams are better and still not a replacement for Kafka or RabbitMQ if delivery guarantees are the requirement.

For strong consistency. Asynchronous replication means acknowledged writes can be lost on failover. If that's unacceptable, you need a different system.

Redis alternatives

The landscape changed substantially after the 2024 license change.

Valkey is the Linux Foundation fork of Redis 7.2.4, BSD 3-Clause licensed, backed by AWS, Google, Oracle, and others. Drop-in compatible for core data types. It has since developed independently, notably atomic slot migration in 9.0, which removes the redirect errors that classic Cluster resharding produces. It's now the default engine on ElastiCache and MemoryDB and is priced 20% below Redis OSS on node-based clusters. Modules do not transfer.

Memcached is simpler and older. Strings only, multi-threaded, no persistence. If all you need is a cache and you never use a data structure, it's a legitimate choice.

Dragonfly is an independent implementation of the Redis and Memcached APIs on a shared-nothing, thread-per-core architecture. One instance uses every core on the machine, so a single node has benchmarked at 6.43 million operations per second on an AWS c7gn.16xlarge. Same RESP protocol, same clients, no application changes.

The practical difference is usually node count. Instacart moved their ad-serving feature store off Redis and cut node count by roughly 80% while improving latency about 50%. Meesho reported a 60% cost reduction and 50% lower latency. In each case a sharded cluster collapsed into a much smaller vertically scaled deployment, taking the resharding runbook with it. Dragonfly also supports SSD tiering in the open distribution, which addresses the cold-data cost problem without moving to a sharded topology.

Two caveats we'd rather state than have you discover: Dragonfly is BSL 1.1 licensed, which permits free self-hosting including commercial use but is not OSI-approved open source, so if permissive licensing is your requirement, Valkey fits better. And module compatibility is partial, so verify coverage if you depend on RedisJSON or RedisTimeSeries semantics.

If you're running a few gigabytes of cache that has never caused you trouble, Redis is fine and switching wouldn't pay for itself. The calculus changes when node count drives your bill or resharding has become a scheduled risk event.

Frequently asked questions

What is Redis used for?

Redis is used primarily for caching, session storage, rate limiting, job queues, leaderboards, real-time analytics, and pub/sub messaging. Since Redis 8.0 it also handles vector similarity search and full-text queries natively, which has made it common in retrieval-augmented generation and semantic caching workloads.

Is Redis a database or a cache?

Both, depending on configuration. Redis is most often deployed as a cache because it stores data in memory and supports automatic expiration. It also offers RDB and AOF persistence, which lets it act as a primary datastore. Its durability guarantees are weaker than a disk-first database because replication is asynchronous, so using it as a system of record is a deliberate tradeoff rather than a default.

Is Redis SQL or NoSQL?

Redis is a NoSQL key-value store. It uses its own command protocol rather than SQL, and stores typed data structures such as strings, hashes, lists, sets, sorted sets, and streams instead of relational tables. Redis 8 added a query engine for search and vector workloads, but it does not support joins or ad-hoc relational queries.

Is Redis still open source in 2026?

Yes. Since Redis 8.0 in May 2025, Redis has been tri-licensed under RSALv2, SSPLv1, or AGPLv3, and AGPLv3 is OSI-approved. Versions 7.4 through 7.8 were source-available only, and versions up to 7.2.4 were BSD 3-Clause.

Who created Redis and when?

Salvatore Sanfilippo created Redis in 2009 while working on LLOOGG, his own real-time analytics startup, after his existing database could not handle the write load. VMware hired him in March 2010 and sponsored his work on the project from that point. He left the project in 2020 and rejoined Redis in December 2024.

Why is Redis so fast?

Redis keeps data in RAM, which removes disk seek latency entirely. It executes commands on a single thread, which eliminates lock contention and context switching. Its data structures are purpose-built for their access patterns, so operations like sorted set range queries run in O(log N + M). Typical latency is in the tens of microseconds for in-memory operations.

Does Redis use multiple CPU cores?

Command execution is single-threaded and uses roughly one core regardless of how many the machine has. Redis 8 added I/O threading, which moves socket reads and writes onto additional threads and helps significantly on connection-heavy workloads, but the command path is still serialized. Scaling past one core requires running multiple Redis processes via Redis Cluster.

What is the difference between RDB and AOF persistence?

RDB writes point-in-time snapshots by forking the process, producing compact files that load quickly but lose everything written since the last snapshot. AOF logs every write operation and replays it at startup, which is more durable but produces larger files and slower cold starts. Running both is common: AOF for durability, RDB for fast restores and backups.

How many hash slots does Redis Cluster have?

Redis Cluster has 16384 hash slots, always. Each key maps to a slot via CRC16(key) mod 16384, and slots are distributed across primary shards. The slot count is fixed and unrelated to the number of nodes. A minimum viable cluster has three primaries.

What is the maximum size of a Redis value?

A Redis string can hold up to 512 MB. Collection types such as lists, sets, sorted sets, and hashes can hold up to 2^32 - 1 elements each, roughly 4 billion. In practice, very large individual values cause latency problems because operations on them block the single command thread.

What is the difference between Redis and Valkey?

Valkey is a fork of Redis 7.2.4 created by the Linux Foundation in March 2024, after Redis moved to a source-available license. It uses the permissive BSD 3-Clause license and is backed by AWS, Google, Oracle, and Ericsson. Core data types and the RESP protocol are compatible in both directions. They have since diverged: Redis folded its module ecosystem into the core, while Valkey focused on engine and cluster improvements such as atomic slot migration.

What is the difference between Redis and Memcached?

Memcached stores strings only, is multi-threaded, and has no persistence or replication. Redis offers typed data structures, persistence, replication, clustering, pub/sub, and since version 8, search and vector capabilities, but executes commands on a single thread. Memcached is a reasonable choice for simple high-throughput string caching; Redis is the better fit for anything requiring data structures or durability.

Related guides

• Valkey vs Redis: Licensing, Performance, and How to Choose
• Redis Best Practices
• Running Redis on Kubernetes
• Mastering Redis Cache
• Redis and Dragonfly Architecture Comparison