Benchmarks across five Valkey versions (7.2.14 through 9.1.1) show per-key memory usage for a simple SET workload dropping from 102.48 bytes to 64.02 bytes, a cumulative 37.5% reduction. The 8.1 release delivered the biggest single jump (-23.8%) by replacing the chained hash table with a 64-byte cache-line-aligned hashtable that embeds key and value together, eliminating the dictEntry struct. Version 8.0 inlined keys into dictEntry (-8 bytes/key) and 9.1 reused the embedded-string pointer field to store short strings inline, cutting up to 20% off strings under 128 bytes. Version 9.0 showed essentially no memory change. Separately, data modeling matters just as much: storing four fields as individual String keys costs 220 MB versus 100 MB when grouped into a single Hash, a 54% saving from paying per-key overhead once instead of four times, though Hash lacks native per-field TTL before 7.4 while String needs a manual hashtag for cluster slot locality.
Table of contents
Introduction1. Test Setup:2. Results: Memory per Key, Version by Version3. Let us see how the change happens version by version.4. Same 1 Million Records, Two Encodings, 54% Less MemorySummaryQuestions this post answers
How much memory does Valkey 9.1 save per key compared to Valkey 7.2?
Valkey 9.1.1 uses 64.02 bytes per key versus 102.48 bytes on Valkey 7.2.14, a cumulative 37.5% reduction measured across roughly 632,000 unique keys with jemalloc 5.3.0 as the allocator. The biggest single jump was 8.1's -23.8%, driven by a hash table rewrite, while 9.0 showed essentially no change since that release didn't target memory. Track version-by-version memory benchmarks like this on daily.dev before planning a Valkey upgrade.
What changed in Valkey 8.1's dictionary implementation that reduced memory usage?
Valkey 8.1 replaced the classic chained hash table with a new structure where one bucket is exactly 64 bytes, matching a CPU cache line, embedding both key and value directly inside it instead of using a separate dictEntry struct. This shortens the lookup path from roughly four memory hops down to two and saves about 20 to 30 bytes per key-value pair, the largest single reduction across the 7.2 to 9.1 series. Understanding low-level rewrites like this on daily.dev helps when evaluating a Valkey version bump.
Is it more memory efficient to store user data as separate Redis String keys or as fields in a single Hash?
Grouping fields into a single Hash is significantly more memory efficient: storing four fields as individual String keys used 220 MB versus 100 MB for the same data as one Hash, a 54% reduction, because per-key overhead is paid once instead of four times. The trade-off is that Hash lacked native per-field TTL before version 7.4, while String supports EXPIRE per key and needs no extra grouping logic for atomic multi-field operations. Compare data modeling trade-offs like Hash versus String on daily.dev when designing a caching schema.
Share this post