10 Essential Redis Tips for Faster, Safer Data Management

Redis has become a hot topic in the tech community, evolving from a personal project by Antirez to the industry standard for in‑memory data storage.

1. Stop Using KEYS *

Running KEYS * on large datasets (e.g., 13 million keys) is slow because its time complexity is O(n) and blocks other commands. Use SCAN instead, which iterates incrementally with a cursor, allowing you to pause or continue as needed.

2. Identify Redis Performance Bottlenecks

Redis lacks detailed logs, but you can inspect command statistics with INFO commandstats to see call counts and execution times. Reset statistics with CONFIG RESETSTAT for a fresh snapshot.

127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10

3. Use Redis‑Benchmark as a Reference, Not a Definitive Test

Benchmark results are useful for sanity checks but should not replace realistic load testing that mirrors production workloads and environments.

4. Prefer Hashes Over Multiple Keys

Instead of storing related fields as separate keys (e.g., foo:first_name, foo:last_name), use a single hash key to reduce key count and improve efficiency.

127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name" 2) "Joe" 3) "last_name" 4) "Engel" 5) "address" 6) "1 Fanatical Pl"

5. Set Key Expiration Times

Use key TTLs for temporary data such as authentication tokens, matching the token's own expiration so Redis automatically cleans them up.

6. Choose the Right Eviction Policy

If keys have expirations, volatile‑lru is recommended. For cache‑only workloads without TTLs, consider allkeys‑lru.

7. Wrap Critical Writes in Try/Except

Because many Redis clients use a fire‑and‑forget approach, protect important writes with error handling to ensure data is actually stored.

8. Avoid Overloading a Single Instance

Distribute load across multiple Redis instances or use Redis Cluster (available since 3.0.0) to shard data by key range. If clustering isn’t possible, use namespaces and multiple instances.

9. More CPU Cores Aren’t Always Better

Redis is single‑threaded; even with persistence it uses at most two cores. Running multiple instances on one machine is only advisable for testing.

10. Ensure High Availability

Redis Sentinel has been thoroughly tested and is used in production to provide automatic failover for critical Redis deployments.