Understanding Redis String Memory Overhead and Optimization Techniques

Redis is a high‑performance key‑value store widely used as a backend memory database, but its default String type can waste memory when storing small numeric key‑value pairs. This article analyzes how String data is stored, the reasons for its memory overhead, and methods to reduce it.

The memory cost arises because Redis stores additional metadata alongside the actual data. It uses a Simple Dynamic String (SDS) abstraction that records the string length, provides constant‑time length retrieval, prevents buffer overflows, and reduces reallocations. An SDS consists of a buf byte array, a len field (4 bytes), and an alloc field (4 bytes).

Beyond SDS, each value is wrapped in a RedisObject that holds metadata such as last access time and reference count, adding another 8 bytes of metadata and two 8‑byte pointers.

Redis further optimizes memory by employing three encoding schemes for strings: int encoding (stores integers directly in the pointer), embstr encoding (stores short strings (< 44 bytes) together with the SDS in a contiguous block), and raw encoding (stores longer strings in a separate SDS with a pointer).

All key‑value pairs are kept in a global hash table, where each entry contains three 8‑byte pointers (key, value, next), totaling 24 bytes. Due to jemalloc’s allocation rounding, a 24‑byte request is rounded up to 32 bytes, contributing to the observed 48‑byte usage for a simple numeric pair.

To mitigate this overhead, Redis offers the compressed list (ziplist) data structure. A ziplist stores entries consecutively without extra pointers, using a header ( zlbytes , zltail , zllen ) and entries that contain a 4‑byte length field and the actual content. For a numeric key‑value pair, a ziplist can reduce storage from 48 bytes to 16 bytes.

Redis also implements higher‑level collections (hash, list, sorted set) on top of ziplists. For single‑value pairs, a two‑level hash encoding can be used: split the key into a hash field and store the remaining parts as hash key/value, achieving the same 16‑byte footprint.

When ziplist usage exceeds thresholds, Redis automatically converts the structure to a regular hash table. The thresholds are controlled by the hash-max-ziplist-entries and hash-max-ziplist-value configuration parameters.

In summary, Redis strings consume extra memory due to SDS and RedisObject metadata, but employing ziplists and appropriate hash encodings can dramatically reduce memory consumption, especially at large scale.