Redis Data Structures Beyond Strings: When to Use What
Sorted sets, streams, hyperloglog, bitmaps — picking the right one is usually a 10x win on memory or latency.
Strings are the lazy default. The fastest way to make Redis sing is to match your problem to the right structure.
Sorted set — ranked leaderboards, time-series, schedulers
ZADD leaderboard 1420 player:1
ZADD leaderboard 1388 player:2
ZREVRANGE leaderboard 0 9 WITHSCORES # top 10
Also perfect for delayed queues: score = executeAt, worker runs ZRANGEBYSCORE 0 now LIMIT 0 1.
Hash — one record, many fields
Instead of user:42:name, user:42:email, user:42:age, use HSET user:42 name Minh email minh@x age 30. Below hash-max-listpack-entries (default 128) Redis packs it in a listpack — a dense array that's dramatically smaller than individual strings.
Stream — a log inside Redis
A persistent append-only log with consumer groups and acknowledgements. Poor-man's Kafka when you're already on Redis and latencies are short.
XADD orders * customer 42 amount 99
XREADGROUP GROUP workers c1 COUNT 10 BLOCK 5000 STREAMS orders >
HyperLogLog — cardinality in 12 KiB
Counting unique visitors over 30 days? PFADD/PFCOUNT gives you cardinality with 0.81% standard error using 12 KiB per HLL, merge-able across keys.
Bitmap — per-user flags at scale
SETBIT active:2026-04-24 USER_ID 1
BITCOUNT active:2026-04-24
A million active-user flags for a day fits in 125 KiB. BITOP OR across days gives monthly actives.
GEO — indexed geospatial
GEOADD locations 106.7 10.77 "office"
GEOSEARCH locations FROMMEMBER office BYRADIUS 2 km ASC
How to pick
If you ever find yourself keeping a sorted index "on the side," using INCR+SET pairs, or serializing a JSON blob just to update one field — step back. There's a dedicated structure waiting to be a 10× win.