Redis Ziplist (Compressed List) Principles and Applications

Abstract

Redis is a well‑known key‑value in‑memory database and a powerful data‑structure service. It supports five data structures—strings, lists, hashes, sets, and sorted sets—each with various encoding options. This article introduces the ziplist (compressed list) encoding, explains its underlying principles, shows how Redis applies ziplists, and analyses the practical impact of these applications.

Redis Ziplist Principles and Applications

A ziplist is a contiguous memory block that stores a series of elements together with their encoding information. The purpose is to minimise memory overhead while keeping access time within acceptable bounds. In Redis 3.2 the implementation resides in ziplist.h and ziplist.c .

Ziplist Principles

The overall memory layout of a ziplist consists of five parts:

zlbytes : a 4‑byte unsigned integer that records the total number of bytes occupied by the ziplist.

zltail : a 4‑byte unsigned integer that stores the offset of the last entry from the start of the ziplist.

zllen : a 2‑byte unsigned integer that holds the number of entries; it becomes invalid when the count exceeds 2^16‑2, requiring a full traversal to determine the size.

entryX : the variable‑length region that contains the actual list entries.

zlend : a single byte with the fixed value 255 that marks the end of the list.

List Element Encoding

Each entry in the ziplist is composed of three fields:

previous length : stores the length of the preceding entry, enabling backward traversal. It occupies 1 byte if the previous entry is shorter than 254 bytes, otherwise 5 bytes (a marker byte 254 followed by a 4‑byte length).

encoding : describes the type (string or integer) and length of the content field. The encoding can be 1, 2, or 5 bytes long, with the first two bits indicating the data type and the remaining bits the length.

content : the actual payload of the entry, whose type and size are determined by the encoding . It may be a byte array or an integer, and under certain conditions its length can be zero.

Redis Applications of Ziplist

Redis employs ziplist encoding in several data structures under specific conditions. The following table (illustrated in the original article) summarises the usage:

In short, three of Redis’s five core data types may use ziplist encoding when certain thresholds (such as element count or element size) are met. Even the GEO type leverages ziplist internally.

Analysis of Ziplist Usage

Redis decides whether to use a ziplist based on a switch and a threshold for each data type. The switch enables or disables ziplist encoding, while the threshold checks conditions like the number of elements or the length of values. Using a ziplist reduces memory consumption and fragmentation by storing many small items in a single contiguous block, which is valuable for an in‑memory database.

However, ziplist operations have O(N) time complexity for insertions and deletions, which becomes costly as N grows, unlike hash tables that provide O(1) access. Therefore, ziplists are advantageous when the number of elements remains moderate.

Beyond memory savings, ziplists also minimise fragmentation by “coalescing” many tiny allocations into one larger allocation, improving overall memory management for Redis.

Conclusion

The article presented the internal structure and encoding of Redis ziplists, demonstrated their usage across various Redis data types, and analysed the trade‑offs of employing ziplists, highlighting both memory efficiency and performance considerations.