Where Redis's Per-Key Overhead Actually Comes From
Every key-value pair in Redis costs more RAM than keySize + valSize. This calculator models that fixed overhead as a flat ~64 bytes per key: a 24-byte dictEntry struct linking the hash table bucket, a 16-byte robj wrapper for the key, a small SDS string header (roughly 3-9 bytes depending on length), and another 16-byte robj for the value. Total memory is ((keySize + valSize) × numKeys) + (64 × numKeys), then inflated by a jemalloc fragmentation ratio — defaulting to 1.15, i.e. 15% — applied as baseMemory × (fragRatio - 1.0) on top.
Why 15% Fragmentation Is Optimistic, Not Conservative
Jemalloc allocates memory in fixed size classes, so a value that's 65 bytes gets rounded up to the next class boundary, not packed tightly. Under steady-state inserts with little churn, 10-15% overhead is a reasonable real-world figure. But workloads with frequent expiry, eviction under maxmemory-policy, or highly variable value sizes fragment far more aggressively — production Redis instances running heavy TTL churn regularly see 30-50% fragmentation, which is exactly what INFO memory's mem_fragmentation_ratio field is for.
When the Overhead Dominates the Data
- Small values amplify overhead: With a 32-byte key and an 8-byte counter value, the ~64-byte fixed cost is more than 1.5x the actual payload — caching many small values (counters, flags, short IDs) is far less RAM-efficient per item than caching fewer, larger ones.
- This is data memory only: Replication backlog buffers, AOF rewrite buffers, and client output buffers for slow consumers are separate allocations this calculator doesn't include, and they can spike RAM usage well past the steady-state number shown here.