NOTE
5.4 Redis Memory Optimization
Modern Redis memory optimization through schema design, bounded cardinality, compact encodings, payload reduction, TTL/eviction, allocator observation, and instance sizing.
This is a historical learning note and may contain outdated or incomplete understanding.
1. Optimize the Data Model First
The largest wins usually come from storing less data:
- reduce unnecessary fields;
- choose compact serialization;
- avoid duplicated indexes unless they serve a real access path;
- bound collection cardinality;
- expire transient data;
- split or redesign oversized objects.
2. Internal Encodings
Redis uses compact internal encodings for small values/collections and changes representation as structures grow.
Historical settings based on ziplist thresholds have evolved to newer encodings such as listpacks/quicklists depending on version. Tune only against the Redis version you actually run.
3. Key Overhead Matters
Millions of tiny key/value pairs can spend a large fraction of memory on key names, object metadata, hash tables, allocator size classes, and pointers.
Grouping closely related fields into appropriately sized hashes can reduce overhead—but do not create one huge hash.
4. Configure a Memory Budget
Use maxmemory plus a deliberate eviction policy for cache workloads, and leave headroom for replication, persistence, client buffers, allocator/COW overhead, and the OS.
5. 32-bit Builds Are Not a Normal Modern Optimization
Older guidance sometimes suggested running a 32-bit Redis binary to save pointer space. The address-space limit and operational constraints make this inappropriate for normal modern deployments.
Optimize schema and instance sizing instead.
6. Measure
Use INFO memory, MEMORY USAGE, allocator stats, big-key sampling, eviction rates, RSS, and workload-level hit ratio/latency before and after changes.