Redis is an in-memory data-structure store — data lives in RAM, so reads and writes return in microseconds instead of milliseconds. It's most often used as a cache sitting in front of a slower database, but the same engine handles sessions, rate limiting, queues, real-time leaderboards and pub/sub messaging. It is not your system of record; it's the speed-and-coordination layer your app leans on. This is how it works, what it's genuinely good for, the honest durability story, and the 2024 licence drama that produced the Valkey fork.
Redis — REmote DIctionary Server — was created by Salvatore Sanfilippo ("antirez") in 2009 and became the default in-memory store of the modern web. At its simplest it's a giant dictionary: you SET a key to a value and GET it back, blisteringly fast, because it all lives in memory.
What makes it more than a glorified hash table is that the values are rich data structures, not just strings. Lists, hashes, sets, sorted sets, streams, bitmaps and more — each with native commands. That's the real differentiator: a leaderboard is a sorted set, a job queue is a list, a rate limiter is a counter with an expiry, a session is a hash. You're not bolting these on top of a dumb store; Redis understands them.
Because it's single-threaded for command execution (an event loop, with I/O threading added in newer versions), operations are atomic and predictable — no surprise race conditions inside a single command. The trade is that one Redis instance uses one CPU core for the main work; you scale out with replication and clustering rather than up.
Think of Redis as your application's short-term memory and nervous system: the place it keeps what it needs instantly (cache, sessions), and the channel through which its parts coordinate (queues, pub/sub, locks). Your database is the long-term memory — the durable record. Redis makes the database fast and the system coordinated; it does not replace it.
Redis earns its place because the same fast in-memory store solves a cluster of common problems that would each otherwise need bespoke infrastructure. The big one is caching; the rest come almost free once it's there.
Store the result of a slow query or API call; serve it from memory until it expires. The classic database-relief pattern.
SET / GET + EXPIREHold user session data outside any single app server, so requests can hit any instance behind a load balancer.
HSET / HGETALLCount requests per user per window with an auto-expiring counter. Throttle abuse without touching the database.
INCR + EXPIREHand background work between producers and workers — simple lists, or durable consumer-group Streams for serious pipelines.
LPUSH / BRPOP · XADDBroadcast events to many subscribers instantly — live notifications, chat fan-out, cache-invalidation signals.
PUBLISH / SUBSCRIBESorted sets keep millions of scores ranked in real time — "top 10", "your rank" — without a single ORDER BY.
ZADD / ZRANGERedis commands read like plain instructions. Here's the cache-aside pattern, a rate limiter, and a queue — the three you'll write most.
# Cache-aside: cache a value for 1 hour SET user:42:profile "{...json...}" EX 3600 GET user:42:profile # hit → return; miss → load from DB, then SET # Rate limit: max 100 requests per minute per user INCR rate:user:42 EXPIRE rate:user:42 60 # first call sets the 60s window # if INCR returns > 100 → reject # Simple job queue LPUSH jobs:email "send:welcome:42" # producer adds BRPOP jobs:email 0 # worker blocks until a job arrives
Almost every Redis use leans on TTL — a key that deletes itself after a set time (EX, EXPIRE). Caches that expire, rate-limit windows that reset, sessions that time out, locks that auto-release if a worker dies: all just keys with an expiry. Master TTL and a surprising share of "we need a background job to clean this up" problems vanish.
Redis can persist to disk, but it is designed memory-first. Understanding exactly what survives a crash is the difference between using it well and losing data you assumed was safe.
Two persistence mechanisms, often combined:
Even with AOF, Redis is not a drop-in replacement for a transactional database with the durability guarantees of PostgreSQL. The right framing: if losing the data would hurt, the source of truth belongs in your real database, with Redis as the fast cache or coordination layer in front. If the data is genuinely ephemeral — a cache, a rate-limit window, a transient queue — memory-first is exactly right.
"There are only two hard things in computer science: cache invalidation and naming things." Redis makes caching trivial to add and easy to get subtly wrong — stale data served after the source changed. Decide your invalidation strategy up front (TTL-based expiry is the simplest and most robust; explicit deletion on write is more precise but easier to miss). A cache that serves wrong answers is worse than no cache.
For most of its life Redis was permissively open source (BSD). In 2024 that changed, the community forked, and the result genuinely affects which one you should reach for. This is the current state — and it's worth getting right before you standardise on a name.
What happened. In March 2024, Redis Inc. relicensed the Redis server away from the permissive BSD licence to a dual RSALv2 / SSPLv1 model — "source-available", not OSI-approved open source — primarily to stop cloud providers reselling Redis-as-a-service without contributing back. The community response was immediate: a fork called Valkey, hosted under the Linux Foundation, BSD-licensed, and backed by AWS, Google Cloud, Oracle, Ericsson and Snap. Valkey is a drop-in continuation of open-source Redis.
Where it landed. In 2025 Redis Inc. added AGPLv3 as an option for Redis 8, restoring an OSI-approved open-source licence alongside the source-available ones. So today you have a genuine choice: Redis (AGPLv3 or the commercial/source-available licences, with Redis Inc.'s modules and ecosystem) or Valkey (BSD, vendor-neutral, drop-in compatible). They speak the same protocol and commands; switching is usually trivial.
| Dimension | Redis | Valkey |
|---|---|---|
| Licence | AGPLv3 or RSALv2 / SSPL | BSD-3 (permissive) |
| Steward | Redis Inc. | Linux Foundation |
| Backers | Redis Inc. + ecosystem | AWS, Google, Oracle, Snap, Ericsson |
| Compatibility | The original | Drop-in; same protocol & commands |
| Managed as | Redis Cloud, Azure, others | AWS ElastiCache / MemoryDB, GCP Memorystore |
| Reach for it when | You want Redis Inc.'s modules / Cloud / support | You want permissive licensing & vendor neutrality |
For most new builds that just need caching, sessions and queues, Valkey is the low-drama default — BSD-licensed, vendor-neutral, and what the major clouds now offer by default (AWS ElastiCache defaults to Valkey, often cheaper than the Redis option). Choose Redis when you specifically want Redis Inc.'s commercial modules, Redis Cloud, or enterprise support, and you're comfortable with AGPL or a commercial agreement. Either way: pin the version and check the licence terms, because this space is still settling.
Redis/Valkey is near-default infrastructure for any app with traffic — but reaching for it reflexively, or treating it as a database, are the two common mistakes.
Caching adds a second source of truth and the invalidation problem that comes with it. Add Redis when you've measured a genuine hot path — the same expensive read served over and over — not pre-emptively because "caching is good." Premature caching buys you stale-data bugs for performance you didn't need. The fast layer is worth it exactly where the slow layer hurts, and not before.
Redis/Valkey gives an outsized performance return for very little cost — which suits lean SA teams, FX-priced cloud, and apps serving users over variable connectivity.
A single small instance of Redis or Valkey can take enormous read load off a database, letting a modest, cheap server handle traffic that would otherwise need a bigger, pricier one. For cost-sensitive builds, a cache is often the highest-return-per-rand piece of infrastructure you can add — and it runs happily in a container next to the app.
For SA studios and in-house teams who want permissively-licensed, no-strings open source — and no AGPL questions to run past a client's legal team — Valkey (BSD) is the straightforward choice, and it's what AWS's af-south-1 ElastiCache offers. Same commands, no licence overhead, often a lower managed price than the Redis option.
Keeping sessions and transient state in Redis rather than in app memory means a deploy, a crash, or a load-shedding restart of one app server doesn't log everyone out. With AOF persistence on a small instance, the fast layer comes back warm. Pair it with PostgreSQL as the durable record and you have a resilient, affordable two-tier data setup.
image: valkey/valkey in a Compose file is a one-line cache.af-south-1.Official Redis and Valkey documentation and the command reference. The licensing situation is still settling — confirm the current licence of the exact version you deploy. Last reviewed 2026-06-18.