Redis is used mainly as a cache in front of a slower database, and after that as a session store, rate limiter, leaderboard, lightweight queue or event stream, pub/sub channel and, more recently, a vector store for AI search. It holds the whole dataset in memory, executes commands one at a time on a main thread, and can persist to disk with RDB snapshots, an append-only file, or both. Those three facts explain why Redis is fast and also where it causes trouble.
Common Redis use cases
Each use case maps to a Redis data type, and each comes with an operational catch:
| Use case | What Redis provides | The catch |
|---|---|---|
| Caching | Strings or hashes with a TTL, plus an eviction policy when memory is full | Without maxmemory and a deliberate eviction policy, a full cache either rejects writes or evicts keys you did not expect |
| Session store | A hash per session with an expiry | Losing the node logs every user out unless persistence or a replica covers it |
| Rate limiting | INCR plus EXPIRE, the rate limiter pattern in the Redis documentation | The counter for one client must live on one node, so key it by client |
| Queues and streams | Lists for simple queues; Streams with consumer groups | Durability depends on persistence settings; see Redis as a message queue |
| Pub/Sub | PUBLISH and SUBSCRIBE | At-most-once delivery: a disconnected subscriber misses messages for good |
| Leaderboards | Sorted sets, ordered by score | One very large sorted set stays on one node, even in a cluster |
| Vector search | Vector sets and the Redis Query Engine in Redis 8; the valkey-search module on Valkey | Embeddings take real memory; size RAM for the vectors, not just the key count |
Redis can also serve as the primary database for data that fits in memory and tolerates its durability model. Most teams run it beside a system of record rather than instead of one.
Redis architecture: one main thread, everything in memory
Redis uses a mostly single-threaded design. One main thread multiplexes all client connections and executes commands sequentially, so every command is atomic without locks, and none of them waits on a disk read because the data is already in memory. The same design sets the main limits:
- One slow command stalls everyone. A
KEYS *over a large keyspace, or a range read across a huge sorted set, blocks every other client until it finishes. UseSCANand bounded ranges, and watch the slow log. - Extra cores help less than you expect. Redis 8 introduced a new I/O threading implementation, enabled with
io-threads, in which I/O threads read and parse requests and write replies while the main thread executes commands. Redis's documentation still points to running more instances, or sharding, to use many cores. - Memory is the capacity limit. A single instance can address 2^32 keys and has been tested with at least 250 million, but most datasets run out of RAM long before that.
Around the main thread sit replication and high availability. Replicas copy the primary asynchronously and can serve reads, Sentinel adds automatic failover for one dataset, and Redis Cluster shards data across several primaries. Our Redis high availability guide compares the options.
Redis persistence: RDB vs AOF
Redis keeps data in memory, but it does not have to lose it on restart. There are four configurations:
| Option | How it works | What you can lose | Cost |
|---|---|---|---|
| RDB | Point-in-time snapshots written to dump.rdb by a forked child process at configured intervals. On by default. | Everything since the last snapshot. Redis's documentation says to be prepared to lose the latest minutes of data. | The fork can pause Redis for milliseconds, or up to a second on a very large dataset with a slow CPU. |
| AOF | Logs every write and replays the log at startup. Enabled with appendonly yes. Since Redis 7.0 the log is a base file plus incremental files tracked by a manifest. | With the default appendfsync everysec, about one second of writes. appendfsync always is safest and slowest. | Larger files, and periodic rewrites that also fork. |
| RDB + AOF | Both run. On restart Redis loads the AOF, because it is the most complete. | As for AOF. | Both of the above. |
| None | Pure in-memory. | Everything, on every restart. | None. Acceptable for a cache that can be rebuilt. |
Redis's own guidance is to use both if you want data safety comparable to PostgreSQL, and RDB alone if you can live with a few minutes of loss. It discourages AOF alone, because periodic RDB snapshots are better for backups and faster restarts.
Two points catch teams out. Persistence is not a backup: the files sit on the same host, so copy them elsewhere on a schedule, as our Redis backup and disaster recovery guide describes. And persistence does not change replication: a primary can acknowledge a write, crash, and fail over to a replica that never received it, whatever appendfsync says.
Where Redis is the wrong tool
- Datasets far larger than RAM, where a disk-based database costs much less per gigabyte.
- Messaging that must survive consumer outages with replay and per-message delivery guarantees, where Kafka or RabbitMQ fit better.
- Ad hoc queries across many fields, unless you adopt the Redis Query Engine and model data for it.
A note on Redis licensing
Which Redis you run affects how you may use it. Redis 7.2 and earlier are BSD-3-Clause. Redis 7.4 is available under RSALv2 or SSPLv1. Redis 8 and later add the AGPLv3 as a third option. Valkey, the fork backed by the Linux Foundation and built from BSD-licensed Redis code, is BSD licensed. For most teams running Redis internally the practical effect is small, but it is worth settling with your legal team before you choose a version. Our Valkey vs Redis comparison covers the differences.
When to get help
Most Redis trouble shows up as one of the catches above: a cache evicting the wrong keys, a snapshot fork pushing a node out of memory, a persistence setting nobody chose on purpose, or one slow command blocking the main thread at peak. If you want a review of how your instances are set up for the jobs they actually do, or engineers on call when they misbehave, AceMQ provides Redis support for open-source Redis and Valkey.
Sources
- Redis: Persistence
- Redis: Diagnosing latency (single-threaded nature of Redis)
- Redis: Benchmarks (scaling across cores)
- Redis: FAQ (key limits)
- Redis: Redis 8 GA announcement (new I/O threading)
- Redis: Redis 8.0-M03 (how the I/O threads work)
- Redis: INCR (rate limiter pattern)
- Redis: Sorted sets (leaderboards)
- Redis: Streams
- Redis: Pub/Sub (delivery semantics)
- Redis: Vector sets
- Redis: Key eviction
- Redis: Licenses
- Redis: Redis is now available under the AGPLv3 (1 May 2025)
- Valkey: Introducing vector search to Valkey
- Valkey: Project home (BSD license)
Frequently Asked Questions
What is Redis used for?
Mostly as a cache in front of a slower database. It is also widely used as a session store, rate limiter, leaderboard, lightweight queue or event stream with Redis Streams, pub/sub channel and, from Redis 8, a vector store for similarity search.
Is Redis a database or a cache?
Both. Redis is an in-memory data store that can persist to disk, so it can act as a primary database for data that fits in memory. Most teams use it beside a system of record, as a cache or for fast shared state, rather than instead of one.
Does Redis save data to disk?
Yes, if configured to. By default Redis writes RDB snapshots to a file called dump.rdb. The append-only file (AOF) logs every write and is enabled with appendonly yes. You can run both, either, or neither for a pure cache.
What is the difference between RDB and AOF in Redis?
RDB takes point-in-time snapshots at intervals, which makes compact files and fast restarts but can lose the minutes since the last snapshot. AOF logs every write and, with the default fsync every second, can lose about one second of writes. Redis recommends both if you want data safety comparable to PostgreSQL.
Is Redis single-threaded?
Mostly. Commands execute one at a time on a main thread, which keeps each command atomic. Redis 8 introduced a new I/O threading implementation, enabled with io-threads, so reading requests and writing replies can use extra threads. To use many cores, Redis still recommends running more instances or sharding.
How much data can Redis lose in a crash?
It depends on persistence. With RDB only, everything since the last snapshot, typically minutes. With AOF and appendfsync everysec, about one second. With no persistence, everything. Asynchronous replication can also lose recent writes during a failover, whatever the persistence setting.
Is Redis still open source?
Redis 8 and later can be used under the AGPLv3, an OSI-approved open source license, as well as RSALv2 or SSPLv1. Redis 7.4 is under RSALv2 or SSPLv1 only, and Redis 7.2 and earlier are BSD. Valkey, the Linux Foundation fork, is BSD licensed.
Go deeper on Redis
- GuideThe Redis Reliability GuideRead the guide
- GuideBuying Redis and Valkey Support: The GuideRead the guide
- GuideThe Redis Backup and Disaster Recovery GuideRead the guide
- GuideRedis for AI: Vector Search, Agent Memory and MCP in ProductionRead the guide
- ComparisonRedis vs Kafka ComparedSee the comparison
- ComparisonValkey vs Redis: Where the Fork and Redis 8.0 DivergeSee the comparison
- ComparisonManaged Redis Options ComparedSee the comparison
- ResearchThe Redis and Valkey CVE Register, 2026 EditionRead the research
