ValkeyConf 2026

Your Valkey server reports 100% CPU. Is it saturated? You cannot tell from that number, and it isn't a monitoring bug.

Valkey's main thread and I/O threads busy-wait for work. A thread waiting burns CPU exactly like a thread working. In one reported case, throughput swept from 217K to 452K QPS- a 2x increase, while main-thread CPU sat flat near 100% the entire way and total CPU pinned at 400%. Every alert, dashboard and autoscaling policy built on that number is reading noise.

Valkey 9.1 shipped the answer: used_active_time_main_thread and used_active_time_io_thread_N, measuring wall clock minus busy-wait and blocking epoll, on a monotonic clock so spare capacity is actually visible.

This session builds a real saturation signal out of INFO:
1. active-time deltas for true per-thread utilization
2. eventloop_duration_sum minus eventloop_duration_cmd_sum to separate I/O from command execution
3. latencystats percentiles to catch what averages hide

Then we tune I/O thread count against it and ship the result with log-format json.

You will leave able to answer "how much headroom do I have?" and to retire the CPU alert that was never going to tell you.

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.

Each datatype in Valkey (Hash, List, Set, Sorted Set) can be encoded internally as a different object depending on how many elements a key of those types has in order to balance between the memory footprint and performance.

While this approach suits the majority of Valkey deployments. If your Valkey instances have a large number of keys, a little tuning can significantly reduce your memory footprint.

Through live demonstrations, we'll show how an open source encoding analyzer helps identify optimization opportunities and safely tune Valkey for production deployments.

We run 840+ Redis 7.2.12 instances on AWS EKS serving ~1.64M operations per second. Facing a performance ceiling, fragmented client tooling, and a licensing dead-end after Redis left BSD, we migrated the entire fleet to Valkey 8.1.5 — with zero application code changes and sub-five-minute rollback.
This talk is an evidence-first walkthrough. We'll cover what actually changed under the hood (production-ready I/O threading, Swiss Table memory layout, deterministic cluster failover) versus what stayed identical (wire protocol, data format, client libraries) — the distinction that made a fleet-wide engine swap a defensibly low-risk decision. We'll share the benchmark methodology behind our results — +31% throughput, −33% P99 latency, and 22–41% memory savings, confirmed across three independent tools — plus the blue-green rollout plan for both Sentinel and Cluster deployments.