How Much RAM Does a Valkey Upgrade Save? Measuring Per-Key Memory from 7.2 to 9.1

Valkey 8.0, 8.1 and 9.1 each cut the memory that Valkey spends on bookkeeping for every key, and the release posts quote numbers like "about 20 bytes per key" and "17 to 44% less string overhead". Then you upgrade a staging node, and used_memory falls by a different amount, or MEMORY USAGE returns a new number for a key that never changed. Both can be correct. The savings depend on your key and value sizes, your data types and whether you run cluster mode. Some of the metrics you would use to measure them also changed meaning between releases. This post lists where each release reduced per-key overhead, quotes the vendor figures as vendor figures, and gives a replica-based method to measure your own saving before you change a node count.

Scope and review date: November 2026. This post covers self-managed Valkey from 7.2 to 9.1.3, the current 9.1 patch released on 26 October 2026. Readers moving from Redis OSS 7.2 start from the same memory layout as Valkey 7.2. Vendor figures are quoted from valkey.io blog posts and GitHub release notes, and source behaviour was read from the tagged Valkey source on 10 November 2026. Commands were checked against the documentation and were not run in a lab, so rehearse them on staging. Anything from 9.2 is labelled as release-candidate behaviour.

Which Valkey releases reduced per-key memory?

Three releases changed how much memory Valkey spends on each key, apart from the key and value bytes themselves. Each one removed a different pointer or allocation, so the savings stack, but they apply to different key shapes.

• 8.0, from the Valkey 8 memory efficiency post: cluster mode keeps one dictionary per hash slot, so each entry drops the two 8-byte pointers that linked keys within a slot. Separately, the key is embedded in the dictionary entry (PR #541).
• 8.1, from A new hash table: the chained dict is replaced by a hashtable of 64-byte buckets that hold up to seven entries. The dictionary entry disappears, and the key and any expire time are embedded in the value object (PR #1186). Large hashes, sets and sorted sets use the same hashtable.
• 9.1, from Reducing Memory Overhead in Valkey 9.1: embedded strings lose their redundant 8-byte pointer (PR #2516), the embedding budget rises from 64 to 128 bytes (PR #3397), and sorted sets in skiplist encoding embed each member in its node (PR #2508).

We found no per-key layout change in the 9.0 release notes, though 9.0 changed how MEMORY USAGE counts an embedded key (covered below).

How much did Valkey's own tests save?

The vendor tests are worth reading closely, because their setup explains most of the gap between their numbers and yours. All of them use small, uniform keys, which is where bookkeeping is the largest share of memory.

The 8.0 test ran a 7.2 primary with two replicas on newer builds, which is also the method used later in this post. Its load was synthetic:

# The synthetic load from the Valkey 8 memory efficiency post
src/valkey-benchmark -t set -n 10000000 -r 10000000 -d 16

Interpretation: every value is 16 bytes, which is close to the best case for per-key savings. It confirms your build behaves like the vendor's, but do not size a fleet from it.

Why does your saving differ from the vendor figure?

Four things decide what an upgrade gives back on your data.

Allocator size classes

Valkey allocates through jemalloc, which rounds every request up to a fixed size class. The 9.0 source comment describes these as 16-byte steps up to 128 bytes. An 8-byte cut that moves an allocation from 88 bytes to 80 saves 16 bytes, because 88 rounds up to 96. One that moves it from 108 to 100 saves nothing, because both round up to 112. This is why the 9.1 post reports a range, and why "a handful of specific lengths see little or no benefit, and a few see a small regression" for sorted set members.

Which encoding a key uses

Each release changed a specific encoding. Small hashes, sets and sorted sets stored as listpack or intset do not use the hashtable for their elements, so they gain only the per-key saving. The 9.1 skiplist change applies only to sorted sets above the listpack limits.

valkey-cli CONFIG GET hash-max-listpack-entries
valkey-cli CONFIG GET zset-max-listpack-entries
valkey-cli CONFIG GET zset-max-listpack-value

Interpretation: the 9.1.3 valkey.conf defaults are 512 hash entries, 128 sorted set entries and 64-byte values. A sorted set with 100 members stays a listpack and gets nothing from the skiplist embedding. One with 129 members becomes a skiplist and does.

The string embedding budget

In 7.2 and 8.0, a string value of up to 44 bytes is stored as embstr, in the same allocation as its object header. From 8.1 the key and any expire are embedded too, and the tagged source for 8.1 and 9.0 embeds the value only when header, key, expire and value together fit in 64 bytes. In 9.1.3 the budget is 128 bytes and the header is 8 bytes smaller. A short key with a TTL and a 40-byte value can therefore be raw on 9.0 and embstr on 9.1.

valkey-cli OBJECT ENCODING session:8f3a
valkey-cli TTL session:8f3a
valkey-cli STRLEN session:8f3a

Interpretation: the three answers give the encoding, whether an expire is embedded, and the value length. Note that the OBJECT ENCODING page still says embstr is limited to 44 bytes. As of November 2026 that matches 7.2 and 8.0 only.

Cluster mode and TTLs

The 8.0 per-slot saving of 16 bytes applies only in cluster mode, so a standalone primary gets only the key-embedding part, about 8 of the 24 bytes. Keys with a TTL gain more in 8.1, about 30 bytes rather than 20, because their entry in the expires dictionary is replaced by a slot in a hashtable bucket. A cache where every key has a TTL and a short value is the shape that gains most.

Which memory metrics can you compare across versions?

Not all of them. Reporting changed alongside the layout, so a metric can move for accounting reasons alone.

• used_memory is the total the allocator handed out. Its definition did not change, so it anchors any comparison.
• used_memory_dataset is used_memory minus used_memory_overhead. In the 7.2 source, the keyspace overhead includes every dictionary entry and one object header per key. From 8.1 those structures no longer exist and the object holding the key counts as data. Across that boundary, part of the "dataset" change is a relabelling.
• keys.bytes-per-key in MEMORY STATS is dataset.bytes divided by keys.count, so it inherits the same shift.
• MEMORY USAGE in 7.2 and 8.0 adds the dictionary entry and the key to the value. From 8.1 it measures the object, which now contains the key, plus the value, and leaves out the key's slot in the hashtable bucket. On 8.1.0 to 8.1.3 it also missed the embedded key for most encodings, fixed in 8.1.4 and 9.0.0 (PR #2290).

valkey-cli INFO memory | grep -E '^(used_memory|used_memory_startup|used_memory_overhead|used_memory_dataset|mem_replication_backlog|mem_fragmentation_ratio):'
valkey-cli MEMORY STATS

Interpretation: record all of these on both sides. Base the decision on used_memory minus used_memory_startup and mem_replication_backlog, divided by keys.count. Read mem_fragmentation_ratio separately: a freshly loaded node has little fragmentation whatever its version.

How do you measure the saving on a staging replica?

Compare two replicas of the same primary: one on your current version and one on the target. Both get the same keys from the same full sync, both start with a fresh heap, and neither handles client writes, so the only difference left is the version. This is the method Valkey used for its 8.0 numbers.

A newer replica of an older primary is the normal rolling-upgrade state. Each full sync forks the primary, so add the replicas in a quiet period or attach them to a staging copy of production.

# Standalone or Sentinel: attach both test replicas to the primary
valkey-cli -h r-old REPLICAOF primary.internal 6379
valkey-cli -h r-new REPLICAOF primary.internal 6379

# Cluster mode: add each one as a replica of a chosen shard primary
valkey-cli --cluster add-node r-new:6379 primary.internal:6379 \
  --cluster-replica --cluster-primary-id <primary-node-id>

Interpretation: start both test nodes with the same cluster-enabled setting and memory-related configuration as production. In cluster mode, attach both to the same shard so they hold the same slots. replica-ignore-maxmemory defaults to yes, so the replicas will not evict keys on their own during the test.

for h in r-old r-new; do
  valkey-cli -h "$h" INFO replication | grep -E '^(master_link_status|master_sync_in_progress):'
  valkey-cli -h "$h" INFO server | grep -E '^valkey_version:'
  valkey-cli -h "$h" DBSIZE
done

Interpretation: wait for master_link_status:up and master_sync_in_progress:0 on both. The key counts should match within the churn of a few seconds. If they differ by more, one replica is still loading or has broken its link.

for h in r-old r-new; do
  mem=$(valkey-cli -h "$h" INFO memory)
  used=$(echo "$mem" | awk -F: '$1=="used_memory"{print $2+0}')
  start=$(echo "$mem" | awk -F: '$1=="used_memory_startup"{print $2+0}')
  backlog=$(echo "$mem" | awk -F: '$1=="mem_replication_backlog"{print $2+0}')
  keys=$(valkey-cli -h "$h" MEMORY STATS | awk 'p{print; exit} $0=="keys.count"{p=1}')
  echo "$h: $(( (used - start - backlog) / keys )) bytes per key over $keys keys"
done

Interpretation: this is the number to size from. The difference between the two lines is the measured saving per key for your real mix of types, sizes and TTLs, including the hashtable buckets that MEMORY USAGE leaves out.

How do you sample per-key memory with MEMORY USAGE?

The totals tell you how much you save. A key sample tells you where it comes from, which you need when the saving is smaller than expected or one key family grows. Take one list of keys and query both replicas with it.

export LC_ALL=C
valkey-cli -h r-old --scan --count 1000 | head -n 20000 > keys.txt

sample() {  # $1 = host; prints key, bytes, encoding, type
  while IFS= read -r k; do
    printf '%s\t%s\t%s\t%s\n' "$k" \
      "$(valkey-cli -h "$1" MEMORY USAGE "$k")" \
      "$(valkey-cli -h "$1" OBJECT ENCODING "$k")" \
      "$(valkey-cli -h "$1" TYPE "$k")"
  done < keys.txt
}
sample r-old > old.tsv
sample r-new > new.tsv

Interpretation: one client call per key is slow but keeps replica load trivial. MEMORY USAGE samples 5 nested elements by default; keep that on both sides, because SAMPLES 0 reads every element of a large key.

join -t $'\t' <(sort -t $'\t' -k1,1 old.tsv) <(sort -t $'\t' -k1,1 new.tsv) |
awk -F'\t' '$2 != "" && $5 != "" {
  n[$4]++; d[$4] += $2 - $5
  if ($3 != $6) moved[$4 ": " $3 " to " $6]++
} END {
  for (t in n) printf "%-6s %7d keys  mean saving %.1f B/key\n", t, n[t], d[t] / n[t]
  for (m in moved) printf "%s  %d keys\n", m, moved[m]
}'

Interpretation: the first block gives the mean saving per data type. The second counts keys whose encoding changed, such as string: raw to embstr on 9.1 or zset: skiplist to btree on a 9.2 release candidate. Keys that expired between the two runs drop out of the join.

When do existing keys pick up the new layout?

When each node loads its data on the new version. The hashtable and key-embedding changes apply as a node builds its keyspace, which on an upgraded node means loading the RDB or AOF at startup. The 9.1 string change is explicit about this: a key becomes embstr under the 128-byte budget when it is written or reloaded, and the 9.1 post notes that "a restart alone is enough to trigger it". A replica that has just done a full sync has re-encoded everything, which is another reason the replica method shows the steady state you will reach.

After production restarts, run OBJECT ENCODING and MEMORY USAGE on a few sampled keys. If they match the 9.1 replica, production has reached the measured state.

The 9.2.0-rc1 notes replace the skiplist for large sorted sets with a B+ tree (btree) and keep small hashes with field expiration as listpacks. Both are 9.2 release-candidate behaviour, with no published per-member figure, so do not plan 9.1 capacity on them.

Which 9.1 patch should the test replica run?

9.1.3 or later. PR #4819, shipped in the 9.1.3 release, fixes a listpack encoding difference that "caused RDB load and replication failures for entries of certain lengths between 9.0 and 9.1.x". The PR says the affected lengths "are reachable in normal use", and that 9.1.0 to 9.1.2 cannot read the 9.0 form. A 9.1.0 replica of a 9.0 primary can therefore fail its full sync partway through, and your measurement never starts.

9.1.3 is also a security release, so plan the production upgrade on it too. The version check in the sync loop above shows what each test replica runs.

The version-by-version load and rollback rules, including what Valkey 8 can and cannot read from a 9.x node, are in the companion post on Valkey RDB versions and upgrade rollback.

How do you turn the measured saving into a node count?

Start from the bytes per key measured on the two replicas and your production key count, then apply the fill target you already run at. The fill target is your existing headroom for fork copy-on-write during snapshots, replication and client buffers, and fragmentation. The upgrade does not change that policy.

# Placeholders: replace every value with your own measurements
awk -v keys=480000000 -v before=182 -v after=151 -v node_gib=52 -v fill=0.75 'BEGIN {
  split(before " " after, bpk, " "); split("before after", label, " ")
  for (i = 1; i <= 2; i++) {
    gib = keys * bpk[i] / 1024^3; s = gib / (node_gib * fill); n = int(s); if (n < s) n++
    printf "%-6s %6.1f GiB  %d primaries at %d%% fill\n", label[i], gib, n, fill * 100
  }
}'

Interpretation: the output is a primary count; multiply by replicas per shard for the node count. If the "after" figure is not at least one whole shard smaller, the upgrade buys headroom rather than a smaller fleet, and that is still worth having.

For an eviction cache at maxmemory, the 9.1 post notes that the saving shows up as a higher hit rate rather than free memory, so check the hit rate before you remove capacity.

Frequently asked questions

Key takeaways

Size your Valkey upgrade with JusDB

JusDB's Valkey performance tuning team can review your key and value shapes, plan and read the side-by-side replica test, and turn the measured bytes per key into a maxmemory and node-count plan for your cluster.

Bring your current version, topology, INFO memory and MEMORY STATS from a replica, and your headroom policy. Your team approves every production change.

Related reading

• Valkey performance tuning: memory, persistence, and cluster config
• Redis memory optimization: encoding, TTLs, and eviction policies
• Valkey 9.1: database ACLs, Lua and I/O threading
• Valkey documentation: MEMORY STATS