What is Redis?

Definition

Redis is an in-memory data store that keeps its dataset in RAM and stores not just strings but data structures such as lists, hashes, sets, sorted sets and streams as values. Because reads and writes usually complete in well under a millisecond, it is widely used as a cache, session store, rate-limiting counter and job queue. It can persist data to disk through point-in-time snapshots (RDB), an append-only command log (AOF), or both.

Also known as: Redis Open Source, Remote Dictionary Server, in-memory data store, Redis cache

Published October 3, 2026

Cache-aside sequence: the app checks Redis first, loads the database on a miss, stores the value, then reads it from memory in a millisecond

A data structure server that lives in RAM

Redis holds the entire dataset in memory and uses disk only for persistence, so reading or incrementing a key usually takes microseconds, network round trip aside. What sets it apart from a plain key-value store is that a value can be a data structure. Pushing onto a list, fetching the top ten entries of a sorted set or updating one field of a hash all happen on the server, with no need to pull the value into the application and write it back.

Commands run one after another on the main thread, which makes every individual command atomic: two clients calling INCR at the same moment never lose an increment. The flip side is that one slow command makes everyone wait.

Type	Typical use
String	Counters, cached JSON or HTML fragments
Hash	Objects made of fields, such as session data
List	Simple queues, the last N events
Set	Unique values: tags, today's distinct visitors
Sorted set	Leaderboards, time-ordered entries, sliding-window limits
Stream	An append-only event log read through consumer groups

Current Redis Open Source releases add JSON, time series, vector sets and probabilistic types such as Bloom filters on top of these.

What it does in real systems

Caching and sessions

The most common job is holding the results of database queries or third-party API calls for a limited time: SET product:42 '{...}' EX 300 stores a value that disappears after five minutes. The broader pattern is covered under cache. When several app servers need to share session data, Redis is a frequent choice for the shared store.

Rate limiting

A fixed-window rate limit needs nothing more than a counter per client per minute:

MULTI
INCR rl:203.0.113.7:202610031405
EXPIRE rl:203.0.113.7:202610031405 60
EXEC
# If the returned count exceeds 100, reject the request with 429

Sending both commands inside MULTI/EXEC avoids a counter that gets created but never receives its expiry because the connection dropped in between. For a smoother limit, a sliding window can be built on sorted sets.

Queues

Producers pushing with LPUSH while workers wait on BRPOP is the simplest possible job queue, but a job is lost if the worker crashes after taking it. Streams close that gap with consumer groups and explicit acknowledgement (XACK): unacknowledged entries can be claimed by another worker. Many popular background-job libraries use Redis as their backbone.

Persistence: how much loss can you accept?

RDB: point-in-time snapshots at configured intervals. Compact files, ideal for backups and fast restarts, but writes since the last snapshot, often several minutes' worth, are lost in a crash.
AOF: every write command is appended to a log. With the default appendfsync everysec, the worst case is about one second of lost writes; always is safer but much slower.
Both: the Redis documentation recommends combining them if you want data safety comparable to a relational database.
None: a valid choice for a pure cache, provided the application works correctly with an empty Redis.

The memory limit (maxmemory) and the eviction policy that decides which keys go when it is reached matter as much as persistence. A cache wants a policy that drops old keys; a queue wants a setting that never silently drops anything.

Licensing changes in 2024 and 2025

Redis 7.2.x and earlier are BSD-3 licensed. In March 2024 later versions (7.4.x to 7.8.x) moved to a dual RSALv2/SSPLv1 licence, neither of which Redis itself describes as open source. From Redis 8 onwards users can choose between RSALv2, SSPLv1 and AGPLv3, the last being an OSI-approved open-source licence. The current wording is on the redis.io licences page. After the 2024 change, the BSD-licensed Valkey project emerged with Linux Foundation backing and includes BSD-licensed Redis code. Running Redis for your own application and offering it to others as a managed service can have different licence implications, so check which case applies to you.

Mistakes worth avoiding

Running KEYS * in production: it blocks the server while it walks every key. Use SCAN instead.
Filling memory with keys that never expire: cache entries need a TTL.
Keeping the only copy of critical business data in a Redis instance with persistence disabled.
Exposing the Redis port to the internet without a password and network restrictions.

Redis belongs to the key-value branch of NoSQL, and in most architectures it runs alongside the main database rather than replacing it.

Related terms

← Back to the glossary