How Redis Ziplist Compresses Memory and When to Use It

Ziplist (Compressed List)

Redis ziplist stores list data in a contiguous memory block. Its layout consists of the following fields:

zlbytes : total memory used by the ziplist.

zltail : offset of the tail entry from the start.

zllen : number of entries (2 bytes, max 65535).

zleng : end‑marker, fixed value 0xFF.

entry1‑N : individual ziplist nodes.

Each node is composed of:

previous_entry_length : length of the previous node.

encoding : encoding type and length of the content.

content : the actual data.

Lookup proceeds by:

Using zltail to locate the last node.

Checking whether the current node matches the target.

If it matches, returning the data.

If not, moving backward by previous_entry_length and repeating.

Because each update may require reallocating memory for up to N nodes, both update and lookup have O(N) complexity.

When Does Redis Use Ziplist?

Redis employs ziplist as the underlying storage for Hash and List types when two conditions are met:

All key and value strings are shorter than 64 bytes.

The number of entries is fewer than 512.

If either condition is violated, Redis automatically converts the structure to a hash table or linked list. The thresholds can be tuned via the configuration parameters hash-max-ziplist-value, hash-max-ziplist-entries, and list-max-ziplist-value.

Why Use Ziplist?

Ziplist consumes significantly less memory than hash tables or linked lists.

Contiguous memory layout improves cache‑friendliness.

For small collections, read/write performance is comparable to traditional structures, making the trade‑off of slightly higher update cost worthwhile.

In essence, ziplist trades a modest increase in update time for substantial memory savings.

Practical Experiment

To illustrate the benefit, an ad‑targeting scenario stores audience packages as {package_id}_{device_id} → true. By grouping entries into pre‑allocated buckets that satisfy the ziplist limits (≤512 entries, ≤64 bytes each), memory usage can be reduced. bucket_count = 1,000,000,000 / 512 ≈ 1.95 M Bucket IDs are computed as:

bucket_id = CRC32(package_id + "_" + device_id) % 2,000,000

Experimental results on 20 million entries:

Dataset Size

Storage Mode

Bucket Count

Memory Used

Fragmentation

Redis Memory

20 M

Ziplist

2 M

928 MB

1.38

1.25 GB

20 M

Ziplist

0.5 M

785 MB

1.48

1.14 GB

20 M

Direct KV

-

1.44 GB

1.03

1.48 GB

Memory fragmentation, defined as OS‑allocated memory / object memory, tends to be higher for ziplist because updates often trigger reallocations. Techniques such as memory alignment, snapshots, or rebuilding from replicas can mitigate fragmentation.

Even with relatively large keys (≈34 bytes), ziplist achieved a 35‑50 % memory reduction; in production, careful design can yield up to 70 % savings.

How Much Memory Does Ziplist Save?

Typical Redis key‑value pairs store an extra 24 bytes for the robj header plus additional overhead from the SDS string representation (e.g., length, allocation, flags). A simple Hello → World pair may require 30‑40 bytes, far exceeding the raw data size.

When stored in a ziplist, only 2 bytes are needed for previous_entry_length and encoding, dramatically reducing per‑entry overhead.

Conclusion

Ziplist provides excellent memory compression for small datasets at the cost of slower updates and higher fragmentation. Understanding the trade‑offs and configuring thresholds appropriately enables substantial storage savings in Redis‑backed applications.