A Redis list of a million elements reports the "quicklist" encoding while a three-element list reports "listpack". Explain how a quicklist is built and what list-max-listpack-size and list-compress-depth control.

## Why a hybrid structure Redis lists must support cheap `LPUSH`/`RPUSH`/`LPOP`/`RPOP` at both ends, at any size, and they are used as queues holding millions of entries. Two naive designs both fail: - A **plain doubly linked list** costs two pointers plus an allocation header plus an SDS header per element — tens of bytes of overhead for a 10-byte element — and scatters elements across the heap, so traversal is a chain of cache misses. - A **single listpack** has almost no per-element overhead and perfect locality, but every insertion in the middle, and any growth that outgrows the allocation, requires reallocating and memmoving the entire blob. At a million elements that is a multi-megabyte memmove on the single command thread. The **quicklist** takes the middle path: a doubly linked list of nodes, where each node is a listpack containing many elements. Pointer overhead is amortised across the elements in a node; realloc/memmove cost is bounded by the node size, not the list size. Pushes and pops touch only the head or tail node. Since Redis 7.0, a list small enough to fit in one node is stored as a bare `listpack` (no quicklist wrapper at all), so `OBJECT ENCODING` returns `listpack` for small lists and `quicklist` for large ones. On Redis 6 and earlier the two encodings were `ziplist` and `quicklist`, with quicklist nodes being ziplists. ## list-max-listpack-size This single setting is overloaded, and the sign selects the mode: - **Positive N** — each node holds at most N elements. Simple, but with variable-length elements a node's byte size is unbounded: 128 elements of 1 MB each is a 128 MB node, which reintroduces the giant-memmove problem. - **Negative N** — each node is capped by size, from a fixed table: `-1` = 4 KB, `-2` = 8 KB (the default), `-3` = 16 KB, `-4` = 32 KB, `-5` = 64 KB. The negative form is the safer default because it bounds the *work* per operation rather than the element count. Larger nodes mean fewer pointers (less memory, better locality) but longer per-node scans and larger memmoves; smaller nodes mean the opposite. 8 KB sits near the sweet spot for typical element sizes, which is why it is the default. Note that an element larger than the node cap gets a node of its own — Redis never splits a single element across nodes. ## list-compress-depth Lists used as queues have a striking access pattern: producers touch the tail, consumers touch the head, and the middle is never read until it reaches an end. `list-compress-depth` exploits that. Its value N means: leave N nodes uncompressed at **each** end and LZF-compress every node in between. `0` (the default) disables compression entirely; `1` compresses everything except the head and tail node; `2` leaves two at each end, and so on. LZF is fast and gives useful ratios on text-like payloads, so a large queue of JSON messages can shrink substantially. The cost: any operation that must read or modify a compressed node (an `LINDEX` into the middle, `LINSERT`, `LRANGE` spanning the interior, `LREM`) must decompress it first, and re-compress after a write. For a strict FIFO queue that never happens; for a list you index into randomly, it turns cheap reads into decompress-per-access. So the decision rule is behavioural, not numerical: compress the interior when the list is genuinely a queue or a capped log that is only ever appended to and consumed from the ends, and leave it at 0 when the middle is read. ## Operational notes - Both settings apply at write time. Changing them does not re-encode existing lists; nodes are re-sized as the list is modified. - Very large lists remain dangerous regardless of encoding: `LRANGE key 0 -1` on a million elements is O(n) in elements returned and blocks the single thread while it serialises the reply. `LPOS`, `LINSERT` and `LREM` are also O(n). Quicklist bounds the *memory layout* cost, not the algorithmic cost of the command. - `DEL` on a huge list frees every node synchronously; `UNLINK` moves the freeing to a background thread, which is the safer habit for multi-million-element lists. - Use `OBJECT ENCODING` plus `LLEN` plus `MEMORY USAGE` to see whether a list's footprint is payload or structure, and remember that with compression enabled `MEMORY USAGE` reflects the compressed size.