ValkeyConf 2026

A year ago at Valkey Keyspace in Amsterdam, a group of us stood in a hallway comparing notes on running Valkey on Kubernetes. None of the operators we'd tried supported all the deployment models Valkey has to offer. By the end of the conversation we'd agreed the community needed an operator that did, one that's fully community-driven and endorsed by the Valkey org itself... so we decided to make one!

This talk is what happened in the year since. We'll show what the valkey-operator does today: declare a ValkeyCluster, and the operator handles topology, role management, rolling updates, and recovery. We'll also share what a year of building an operator in the open has taught us.

Most operators have to work around their database. An official one gets a seat at the table to change it. We'll cover the year-two roadmap, plus the conversations underway with Valkey core maintainers on making Valkey itself more cloud native: cgroup awareness to unlock dynamic vertical autoscaling, and module support that's easy to configure.

If you run Valkey on Kubernetes, or want a say in what an official operator becomes, this talk is your invitation to help shape year two.

Synthetic benchmarks measure how fast Valkey can run. Production measures how long it remains predictable, and those are different questions.
Under sustained, high-volume write ingestion, as in a production-scale CDC pipeline, raw throughput is rarely the limiting factor. Instead, clusters become unstable when replication falls behind during resharding, memory amplification exhausts available headroom before eviction recovers capacity, or failover triggers large-scale reconnect storms.
These failure modes rarely appear in benchmark reports, but they're often responsible for production outages.
Using a production-scale CDC workload as the reference system, we'll investigate how Valkey behaves under sustained write load, exploring:

* Why is replication an early warning signal of cluster instability?
* How do resharding, replica promotion, and failover interact under write load?
* Why adding replicas doesn't always improve resilience.
* The operational signals and metrics that reveal instability before users do.

You'll leave with practical heuristics for capacity planning, shard sizing, observability, failover testing, and operating Valkey clusters under sustained write pressure.

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.

Why should a 50GB database require 100GB of RAM just to take a backup or sync to a replica? Valkey’s Forkless Save & Sync capabilities decouple data persistence from the memory-intensive forking process, eliminating the memory spikes that lead to out-of-memory (OOM) issues. We will compare traditional fork-based persistence against the new forkless model, highlighting the impact on system resource utilization. Learn how Valkey helps you configure your clusters for true operational stability.

Forkless Save/Sync is one of the most anticipated features coming to Valkey. The talk at Unlocked/Seattle was well regarded. This talk will cover similar material, but will have increased focus on full-sync.

While fork/forkless is a fairly advanced topic, the concepts are introduced with suitable foundation such that beginners will be able to understand the concepts and impacts. The talk is designed to appeal to all audiences, while still capturing the attention of advanced engineers.

Note: I'm answering "no" to "presented this talk before" because I'll be changing some of the content. However, yes, most of it will come from my presentation at Unlocked/Seattle.

After a Booking.com accommodation reservation, our post-booking service caches reconstructible reservation and order data for web/mobile journeys. To retire self-managed Redis OSS, we first used ElastiCache for Valkey with cluster mode disabled, retained Jedis to limit scope, and routed reads/writes to the primary for read-after-write consistency. At 10% traffic, cache-read p99 rose ~5→15 ms; at 50%, it reached ~50 ms with ~100 ms spikes, and service-latency compliance fell to ~97%, breaching its 99% SLO. Valkey execution remained 20–30 μs, shifting our investigation beyond the engine.

We then enabled a one-shard, three-AZ cluster and moved to Lettuce 6.6.0 with adaptive and 60-second periodic topology refresh and lowest-latency reads across primary and replicas. We accepted eventual consistency for this reconstructible cache; writes remained primary-routed. These changes cut cache-read p99 ~50→3 ms (~94%), but GraphQL p99 remained ~800 versus ~600 ms. Lock telemetry exposed retry waves and redundant loads; retry jitter and cache rechecks cut contended-lock p99 by ~70% and restored GraphQL p99 to ~610 ms, near its ~600 ms pre-migration baseline, completing the migration.

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.

LLMs can write code, answer questions, and execute tasks, but they have one major limitation: they forget. Every new conversation starts from scratch unless we explicitly build systems that preserve context, state, and memory.

In this talk, we'll explore what it actually takes to give AI agents memory. Rather than focusing on prompts or models, we'll focus on the infrastructure layer that sits behind them. We'll examine common memory patterns used in agentic systems, including conversation history, session state, semantic caching, user preferences, and long-term knowledge retrieval.

Using Valkey as the foundation, we'll discuss design decisions, trade-offs, and operational challenges such as memory growth, retrieval latency, cache invalidation, and observability. We'll also look at how memory architectures impact both response quality and inference costs.

The goal is not to build another chatbot. The goal is to understand how stateful AI systems are engineered and why memory is becoming one of the most important infrastructure problems in modern AI.

Agent workloads make a lot of LLM calls. A surprising number of them are redundant. Every call you serve from cache is latency and money you don't pay for.

There is no single cache, but a stack, and Valkey can fit at every level - from the cheap and brittle to the smart and careful. Exact-match response caching on vanilla Valkey. Embedding caches, the layer most people forget, which saves you from paying to vectorize the same text. Then semantic caching with valkey-search, for queries that mean the same thing but don't match byte-for-byte.

I go deep on semantic because it is where most production setups quietly break. The usual setup is one global similarity threshold for everything, and it can't win: set it loose and you serve confident wrong answers, tighten it and your hit rate collapses to almost nothing, and the worst part is you can't tell which until someone complains about a bad response in production. I will show why, and what works instead: per-category thresholds, confidence bands, and how to check a hit is correct before you trust it.

You don't need to know LLMs to follow along. You will leave knowing which cache solves which problem, and where Valkey fits in each.

Are you sure your in-memory datastore is truly secured against unauthorized access, accidental key overrides, and data exposure in production?

Securing Valkey goes far beyond setting a single cluster password. As microservice architectures scale, developers must balance zero-trust isolation with low latency. In this talk, we bridge the gap between application code and Valkey security models. We will explore practical strategies for implementing granular Access Control Lists (ACLs), mutual TLS (mTLS) certificate mapping, and secure connection pooling without sacrificing execution speed.

We'll also dive into recent enterprise security enhancements across modern Valkey releases, including database-level ACL scoping (db=N), enterprise LDAP integration, and automated TLS certificate rotation. You'll walk away with actionable code patterns for multi-tenant key isolation, least-privilege command restrictions, and audit logging.

Whether you're building high-throughput microservices or managing sensitive cached datasets, this session equips you with the tools to build a robust defense-in-depth architecture.
Excited to share best practices and secure our Valkey applications together!