--- title: Valkey Memory Optimization, Version by Version and... description: 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... canonical: https://daily.dev/posts/valkey-memory-optimization-version-by-version-and-encoding-how-many-bytes-did-each-release-actuall-5irzo7vsj twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Valkey Memory Optimization, Version by Version and Encoding: How Many Bytes Did Each Release Actually Save? | daily.dev og:description: 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... og:url: https://daily.dev/posts/valkey-memory-optimization-version-by-version-and-encoding-how-many-bytes-did-each-release-actuall-5irzo7vsj og:image: https://api.daily.dev/og/posts/5irzo7vSj.png og:image:alt: Valkey Memory Optimization, Version by Version and Encoding: How Many Bytes Did Each Release Actually Save? og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Valkey Memory Optimization, Version by Version and Encoding: How Many Bytes Did Each Release Actually Save? **[Percona Blog](https://daily.dev/sources/percona)** · 6 min read · 1 upvotes · 0 comments ## Summary 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. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions 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._ ## Similar posts on daily.dev - [Valkey · Reducing Memory Overhead in Valkey 9.1](https://daily.dev/posts/valkey-reducing-memory-overhead-in-valkey-9-1-71iizc4rp) · Valkey · 10 upvotes · 0 comments - [\[Video Podcast\] Improving Valkey with Madelyn Olson](https://daily.dev/posts/video-podcast-improving-valkey-with-madelyn-olson-bjpwcn9zl) · InfoQ · 0 upvotes · 0 comments - [Announcing Valkey 9.1 for Amazon ElastiCache](https://daily.dev/posts/announcing-valkey-9-1-for-amazon-elasticache-pvemznhnh) · AWS Database Blog · 0 upvotes · 0 comments - [Memorystore for Valkey 9.0 is now GA](https://daily.dev/posts/memorystore-for-valkey-9-0-is-now-ga-rbykebtbw) · Google Cloud · 0 upvotes · 0 comments - [Valkey 9.1 Delivers More Performance & Enhanced Security](https://daily.dev/posts/valkey-9-1-delivers-more-performance-enhanced-security-9lzgcvzst) · Phoronix · 0 upvotes · 0 comments --- Tags: [#redis](https://daily.dev/tags/redis), [#data-structures](https://daily.dev/tags/data-structures), [#valkey](https://daily.dev/tags/valkey) [View this post on daily.dev](https://daily.dev/posts/valkey-memory-optimization-version-by-version-and-encoding-how-many-bytes-did-each-release-actuall-5irzo7vsj) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Valkey Memory Optimization, Version by Version and Encoding: How Many Bytes Did Each Release Actually Save?","url":"https://daily.dev/posts/valkey-memory-optimization-version-by-version-and-encoding-how-many-bytes-did-each-release-actuall-5irzo7vsj","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/valkey-memory-optimization-version-by-version-and-encoding-how-many-bytes-did-each-release-actuall-5irzo7vsj"},"datePublished":"2026-09-29T15:47:19.693Z","dateModified":"2026-09-29T19:20:39.104Z","description":"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...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Percona Blog","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Percona Blog","logo":"https://media.daily.dev/image/upload/s--Lb3XkBh3--/f_auto,q_auto/v1780213412/logos/percona?_a=BAMAMiWQ0","url":"https://daily.dev/sources/percona"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/valkey-memory-optimization-version-by-version-and-encoding-how-many-bytes-did-each-release-actuall-5irzo7vsj","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"redis,data-structures,valkey","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Percona Blog","item":"https://daily.dev/sources/percona"},{"@type":"ListItem","position":3,"name":"Valkey Memory Optimization, Version by Version and Encoding: How Many Bytes Did Each Release Actually Save?"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/valkey-memory-optimization-version-by-version-and-encoding-how-many-bytes-did-each-release-actuall-5irzo7vsj#faq","mainEntity":[{"@type":"Question","name":"How much memory does Valkey 9.1 save per key compared to Valkey 7.2?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"What changed in Valkey 8.1's dictionary implementation that reduced memory usage?","acceptedAnswer":{"@type":"Answer","text":"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."}},{"@type":"Question","name":"Is it more memory efficient to store user data as separate Redis String keys or as fields in a single Hash?","acceptedAnswer":{"@type":"Answer","text":"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."}}]} ```