ValkeyConf 2026

For most Valkey deployments, the first wall you hit isn't CPU, it's memory capacity. So what if simply upgrading gave a large fraction of that memory back — with no client changes, no re-sharding, no application rewrites?

This talk goes behind the scenes on the memory-efficiency work that has quietly reshaped Valkey since its earliest releases. Measured on the same hardware across successive versions, per-key overhead has fallen roughly 35–60% across every core data type — strings, hashes, sets, and sorted sets. We'll take a single key apart to see exactly where its memory goes, then watch each of those costs shrink or disappear from one Valkey version to the next. Two ground-up rewrites anchor the story: a cache-friendly hashtable, and the new B+tree-based sorted set that drives per-element cost lower still. A theme runs throughout: on modern hardware, smaller data is usually faster data, because these workloads are bound by memory and cache, not compute.

Expect concrete numbers, under-the-hood analysis, and a clear picture of what the savings mean in practice — more data per node, fewer nodes, and a smaller bill — all delivered transparently, just by staying current.