Master Redis Memory: 7 Proven Techniques to Store More Data with Less RAM

This article explains how Redis stores data internally and presents seven practical techniques to reduce memory usage while storing more data.

How Redis Stores Key‑Value Pairs

Redis centers its storage around the redisDb structure (see source at https://github.com/redis/redis/blob/7.0/src/server.h). The most important fields are:

dict : a global hash table that holds all key‑value objects.

expires : stores expiration information for keys.

blocking_keys and ready_keys : support blocking commands such as BLPOP .

watched_keys : used by the WATCH command for transactions.

id : the database ID (Redis supports up to 16 databases by default).

clusterSlotToKeyMapping : maps keys to hash slots in cluster mode.

The dict structure is a hash table similar to Java's HashMap. Its definition can be found at https://github.com/redis/redis/blob/7.0/src/dict.h:

struct dict {
    dictType *type;
    dictEntry **ht_table[2];
    unsigned long ht_used[2];
    long rehashidx;
    int16_t pauserehash;
    signed char ht_size_exp[2];
};

Key lookup is O(1) because the hash value maps to a bucket in ht_table. Each bucket holds a dictEntry:

typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;
} dictEntry;

key points to a string.

v is a union; when the value fits in uint64_t, int64_t or double, no extra allocation is needed, reducing fragmentation.

next links entries that share the same hash bucket (chaining).

Each entry points to a redisObject that stores metadata and a pointer to the actual data:

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    unsigned lru:LRU_BITS;
    int refcount;
    void *ptr;
} robj;

type : object type (string, list, set, hash, zset, etc.).

encoding : how the value is encoded; different encodings have very different memory footprints.

lru : last access time for LRU/LFU eviction.

refcount : reference count for manual garbage collection.

ptr : points to the actual data structure.

1. Key‑Value Optimization

Shortening keys and values directly reduces memory. Use concise prefixes such as u:fs:996 instead of users:friends:996. For values, filter unnecessary fields, store enums as integers, compress large payloads (e.g., GZIP, Snappy), and choose compact serialization formats like Protostuff or Kryo.

2. Small Collection Encoding Optimization

Redis automatically selects compact encodings for small collections. For example, a hash with few entries and short values uses a ziplist; a list uses quicklist (ziplist + linked list). The default thresholds (e.g., hash-max-ziplist-entries 512, hash-max-ziplist-value 64) can be tuned.

String Encoding

int : integers < 20 digits stored directly in *ptr.

embstr : contiguous allocation for strings ≤ 44 bytes.

raw : dynamic allocation for larger strings (up to 512 MB).

List Encoding

ziplist : used when element count < hash-max-ziplist-entries and each element < hash-max-ziplist-value.

quicklist : default since Redis 3.2; combines ziplist segments with a doubly‑linked list.

Set, Hash, Sorted Set Encoding

Sets use intset for pure integer members; otherwise a hashtable.

Hashes use ziplist for small collections, otherwise a hashtable.

Sorted sets use ziplist for tiny sets, otherwise a skiplist.

3. Object Shared Pool

Redis pre‑allocates a shared pool of integer objects (0‑9999) to reuse common values, saving memory. However, the pool becomes ineffective when maxmemory with LRU eviction is enabled or when ziplist‑encoded collections store integers, because the overhead of tracking usage defeats sharing.

4. Bit‑Level Operations (Bitmap)

For binary state tracking (e.g., user login status), use a bitmap where each bit represents a user. This reduces storage from one byte per user to one bit, achieving up to 8× compression. HyperLogLog can be used for approximate cardinality (e.g., UV counting).

5. Hash Type Optimization

Store related fields of an entity in a single hash instead of separate keys. For a user, use hset users:shenzhen:999 name "Susan" rather than individual string keys, which would create many redisObject instances.

hset users:shenzhen:999 name Susan
hset users:shenzhen:999 age 18
hset users:shenzhen:999 hobby "coding"

6. Memory Fragmentation Optimization

Fragmentation occurs because the OS allocator works with fixed‑size blocks and because keys are frequently created, resized, and deleted. In Redis <4.0 you must restart (RDB reload or master‑slave failover) to defragment. From Redis 4.0 onward, use memory purge for manual cleanup or enable active defragmentation:

config set activedefrag yes
# optional thresholds
active-defrag-ignore-bytes 200mb
active-defrag-threshold-lower 6
active-defrag-cycle-min 15
active-defrag-cycle-max 50

7. Using 32‑Bit Redis

A 32‑bit Redis instance uses smaller pointers, reducing per‑key overhead, but limits total memory to <4 GB. Deploy multiple 32‑bit nodes in a cluster to scale beyond that limit. RDB/AOF files are architecture‑agnostic, so a 64‑bit Redis can restore a 32‑bit backup.

Conclusion

By applying these seven memory‑saving tricks—optimizing key/value length, leveraging compact encodings, reusing integer objects, employing bitmaps, consolidating data in hashes, defragmenting memory, and optionally running 32‑bit instances—you can dramatically increase the amount of data stored in Redis without additional hardware.