Next steps: Redis Stack, modules and choosing a store
JSON documents, search, time series and probabilistic types, plus an honest test for when Redis is the wrong tool and where to read next.
What the modules add
# JSON documents with path-level updates
JSON.SET product:1 $ '{"name":"Kettle","price":29.99,"tags":["kitchen"]}'
JSON.GET product:1 $.tags
JSON.ARRAPPEND product:1 $.tags '"sale"'
JSON.SET product:1 $.price 24.99
# secondary index over JSON, then query it
FT.CREATE idx:product ON JSON PREFIX 1 product: SCHEMA
$.name AS name TEXT
$.price AS price NUMERIC SORTABLE
$.tags[*] AS tags TAG
FT.SEARCH idx:product '@tags:{kitchen} @price:[-inf 30]' SORTBY price ASC LIMIT 0 10
# time series with retention and downsampling rules
TS.CREATE metrics:temp RETENTION 86400000
TS.ADD metrics:temp * 21.5
TS.RANGE metrics:temp - + AGGREGATION avg 60000
# probabilistic types
BF.RESERVE bloom:seen 0.01 1000000
BF.ADD bloom:seen user:42
BF.EXISTS bloom:seen user:42
CMS.INCRBY cms:pages home 1
TOPK.RESERVE top:queries 10| Module | Use | Alternative |
|---|---|---|
| JSON | Document storage with partial updates | A hash, or your primary database |
| Search | Secondary indexes and full-text search over JSON or hashes | Elasticsearch, or PostgreSQL full-text search |
| Time series | Metrics with retention and downsampling | A real time-series database for serious analytics |
| Bloom / Cuckoo | Probabilistic existence checks | A plain set, at much higher memory |
| Top-K / Count-min | Heavy hitters and approximate counts | Sorted sets for exact small datasets |
💡
A module exists so you do not have to build the data structure yourself - it does not change what Redis is. If the data must survive a crash exactly, the durability argument is the same as for any other Redis key, so keep the source of truth where it belongs.
When Redis is the wrong choice
- You need transactional multi-key guarantees across unrelated keys. Redis transactions are per-instance and there is no rollback.
- You need ad-hoc queries, joins or aggregation. Use a relational database; a sorted set is not a query language.
- The dataset must be durable without careful configuration and an operational plan. Redis can be durable, but it is not durable by default in the way a database is.
- You need to store a growing blob. Keys are small; a 10MB value blocks the server while it is served.
- You are storing it because it is fast. Measure the access pattern first - a well-indexed database read is often a few hundred microseconds, and the caching layer may be adding latency and a consistency problem for nothing.
- The data is the primary record for billing, inventory or anything audited. Put it in a transactional store and cache a projection if needed.
The honest framing is that Redis is a data structure server with an in-memory working set. Its strengths are atomic operations on those structures, extremely low latency and a small, well-understood feature set. Everything else follows from those.
Where to read next
- Read the official command reference for the commands you actually use. The complexity annotation next to each command is the single most useful thing on those pages.
- Study the keyspace notifications feature: it turns many polling loops into event-driven code, with the caveat that events are fire-and-forget.
- Learn one client library thoroughly, including its pooling, retry and cluster behaviour, rather than switching between several.
- Read the Redis persistence and replication documentation end to end before you rely on either for data you cannot regenerate.
- Build a small project that uses streams with consumer groups and a reclaim loop. It is the pattern that most repays the effort and the one most often implemented incorrectly.
- Compare against a purpose-built store for each new use case: a time-series database, a search engine, a message broker. Redis can do a version of all of them, and specialised tools exist for a reason.
The measure of fluency with Redis is not knowing every command. It is recognising when a data structure gives you atomicity for free, when it does not, and when a different system should own the data entirely.
FAQ
Should I use Redis for primary storage?
Only when you accept that durability depends on configuration and testing you have done yourself. For most services the primary record belongs in a transactional database, with Redis holding a derived cache, a session, a rate limit counter or a queue.
Search module or a separate search engine?
The Redis search module is excellent for straightforward filtering and ranking over data you already keep in Redis, and it removes a synchronisation problem. Move to a dedicated engine when you need complex relevance tuning, large-scale faceting or analytics.
Related
Clustering and client libraries in applications Transactions, Lua scripting and atomicity
Last refreshed 2026-09-18.