BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:valkeyconf2026
X-WR-CALDESC:Event Calendar
METHOD:PUBLISH
CALSCALE:GREGORIAN
PRODID:-//Sched.com ValkeyConf 2026//EN
X-WR-TIMEZONE:UTC
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T053000Z
DTEND:20261005T150000Z
SUMMARY:Registration & Badge Pick-Up
DESCRIPTION:\n
CATEGORIES:REGISTRATION
LOCATION:Congress Hall Foyer\, Level 0\, Prague\, Czechia
SEQUENCE:0
UID:5c5da930a4b0d85d1139c0864adfd86f
URL:http://valkeyconf2026.sched.com/event/5c5da930a4b0d85d1139c0864adfd86f
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T070000Z
DTEND:20261005T071000Z
SUMMARY:Welcome & Opening Remarks
DESCRIPTION:\n
CATEGORIES:KEYNOTE SESSIONS
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:aa29ccb0ec62494d1fc6f5312d583f40
URL:http://valkeyconf2026.sched.com/event/aa29ccb0ec62494d1fc6f5312d583f40
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T071000Z
DTEND:20261005T075000Z
SUMMARY:Keynote Sessions to be Announced
DESCRIPTION:\n
CATEGORIES:KEYNOTE SESSIONS
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:c9ed418afee4ce70d1473ae1ece229d8
URL:http://valkeyconf2026.sched.com/event/c9ed418afee4ce70d1473ae1ece229d8
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T075000Z
DTEND:20261005T082000Z
SUMMARY:One Year From the Hallway: The State of the Valkey Operator - Joe Heyburn\, Braze & Björn Svensson\, Ericsson
DESCRIPTION: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.
CATEGORIES:ECOSYSTEM/INTEGRATIONS
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:749488481bb647e6a03bb8d7317b019a
URL:http://valkeyconf2026.sched.com/event/749488481bb647e6a03bb8d7317b019a
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T082000Z
DTEND:20261005T085000Z
SUMMARY:Beyond Throughput: Production Lessons From Running Write-Heavy Valkey Clusters - Shuva Jyoti Kar\, Palo Alto Networks & Aditi Gupta\, Disney+ Hotstar
DESCRIPTION: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.
CATEGORIES:ARCHITECTURE
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:33798d2784f44f83cdf26874eedc9d03
URL:http://valkeyconf2026.sched.com/event/33798d2784f44f83cdf26874eedc9d03
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T085000Z
DTEND:20261005T092000Z
SUMMARY:Measuring Valkey Saturation With Active-Time and Eventloop Metrics in 9.1 - Himanshu Sangshetti\, Mem0
DESCRIPTION: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.
CATEGORIES:PERFORMANCE
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:778d9eb05e929658c998552967cf96bb
URL:http://valkeyconf2026.sched.com/event/778d9eb05e929658c998552967cf96bb
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T092000Z
DTEND:20261005T095000Z
SUMMARY:Coffee Break
DESCRIPTION:\n
CATEGORIES:MEALS+BREAKS+SPECIAL EVENTS
LOCATION:Forum Hall Foyer\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:b14c3dbd60fdc4bba1f11d56186e86ea
URL:http://valkeyconf2026.sched.com/event/b14c3dbd60fdc4bba1f11d56186e86ea
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T095000Z
DTEND:20261005T101000Z
SUMMARY:No Client Changes Required: Making Existing Workloads Faster With Less RAM - Rain Valentine\, Amazon
DESCRIPTION: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.
CATEGORIES:PERFORMANCE
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:e03a49719133a45779c9bf6762f02c74
URL:http://valkeyconf2026.sched.com/event/e03a49719133a45779c9bf6762f02c74
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T101000Z
DTEND:20261005T102000Z
SUMMARY:Where Did All My Memory Go? Tuning Valkey Memory Usage at Scale - Edith Puclla & Hieu Nguyen\, Percona
DESCRIPTION: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.
CATEGORIES:PERFORMANCE
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:388d32a2c4dedc0ea77850375d493435
URL:http://valkeyconf2026.sched.com/event/388d32a2c4dedc0ea77850375d493435
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T102000Z
DTEND:20261005T104000Z
SUMMARY:Beyond Fork(): Memory-Efficient Snapshots & Full Sync for Valkey - Jim Brunner\, Amazon AWS
DESCRIPTION: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.
CATEGORIES:FEATURES (VALKEY 10.0)
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:b319c30bdbe9e903a30aed01fc1fe816
URL:http://valkeyconf2026.sched.com/event/b319c30bdbe9e903a30aed01fc1fe816
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T104000Z
DTEND:20261005T110000Z
SUMMARY:Beyond Compatibility: Debugging Tail Latency in a Production Valkey Migration - Anyang Li\, Booking.com B.V.
DESCRIPTION: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.
CATEGORIES:USE CASES/ADOPTION
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:660ecab662186dedac90f574f26b8df0
URL:http://valkeyconf2026.sched.com/event/660ecab662186dedac90f574f26b8df0
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T110000Z
DTEND:20261005T121500Z
SUMMARY:Attendee Lunch
DESCRIPTION:\n
CATEGORIES:MEALS+BREAKS+SPECIAL EVENTS
LOCATION:Forum Hall Foyer\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:d5b6714cfce05f340fa93ad160c96485
URL:http://valkeyconf2026.sched.com/event/d5b6714cfce05f340fa93ad160c96485
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T122500Z
DTEND:20261005T124500Z
SUMMARY:Large Scale Redis To Valkey Migration Along With GLIDE - Premkumar Patturaj\, Freshworks
DESCRIPTION: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.
CATEGORIES:PERFORMANCE
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:cf178ea75f176d7ba0aaabcc521d7b85
URL:http://valkeyconf2026.sched.com/event/cf178ea75f176d7ba0aaabcc521d7b85
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T124500Z
DTEND:20261005T130500Z
SUMMARY:Why AI Agents Forget: Engineering Memory Systems with Valkey - Sanika Kotgire\, ZS Associates
DESCRIPTION:\n 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.\n\nIn 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.\n\nUsing 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.\n\nThe 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.
CATEGORIES:USE CASES/ADOPTION
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:adea8c2eaa57e9808cef01f21506ca92
URL:http://valkeyconf2026.sched.com/event/adea8c2eaa57e9808cef01f21506ca92
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T130500Z
DTEND:20261005T133500Z
SUMMARY:Caching the LLM Stack: Where Valkey Fits To Cut Latency and Cost - Kristiyan Ivanov\, BetterDB
DESCRIPTION: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. \n \n 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. \n \n 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. \n \n 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.
CATEGORIES:USE CASES/ADOPTION
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:f0ed0b583779f474f30683687fa87c22
URL:http://valkeyconf2026.sched.com/event/f0ed0b583779f474f30683687fa87c22
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T133500Z
DTEND:20261005T140500Z
SUMMARY:Coffee Break
DESCRIPTION:\n
CATEGORIES:MEALS+BREAKS+SPECIAL EVENTS
LOCATION:Forum Hall Foyer\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:98ddec77972275d0d46185f2c2dae2fa
URL:http://valkeyconf2026.sched.com/event/98ddec77972275d0d46185f2c2dae2fa
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T140500Z
DTEND:20261005T142500Z
SUMMARY:Reduce LLM Inference Cost up To 80% Using a KV Cache With Valkey - Chaitanya Nuthalapati\, Amazon Web Services
DESCRIPTION:Agentic AI applications are GPU intensive and expensive to run. KV caching allows reuse of computed work for repeated context to reduce latency and costs by up to 80%. This talk explains how KV caching works and walks through a production architecture using vLLM as the inference engine and Valkey as a distributed cache. The talk examines performance implications of cache tuning with LMCache and recent innovations in Valkey that break the ceiling on this performance. You will leave with practical implementation guidance and a framework for evaluating when a database-backed KV cache tier improves your AI application.
CATEGORIES:ECOSYSTEM/INTEGRATIONS
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:e20bb7c6f5fcd232204a7989c6ff902a
URL:http://valkeyconf2026.sched.com/event/e20bb7c6f5fcd232204a7989c6ff902a
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T144500Z
DTEND:20261005T150500Z
SUMMARY:Securing Valkey in Production: Developer Best Practices for Auth\, ACLs\, and Data Protection - Sakshi Nasha\, Cohesity
DESCRIPTION:Are you sure your in-memory datastore is truly secured against unauthorized access\, accidental key overrides\, and data exposure in production? \n \n 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. \n \n 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. \n \n 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. \n Excited to share best practices and secure our Valkey applications together!
CATEGORIES:FEATURES (VALKEY 10.0)
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:7d8e8e295ce6a99129869aea1f892ec9
URL:http://valkeyconf2026.sched.com/event/7d8e8e295ce6a99129869aea1f892ec9
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T150500Z
DTEND:20261005T151500Z
SUMMARY:A Field Guide To Your First Valkey Operator PR - Sagar Utekar\, CrowdStrike
DESCRIPTION:The Valkey ecosystem is bigger than the server: operators\, Helm charts\, clients\, and tooling\, all short on contributors. I recently went from running Valkey to landing merged PRs in the Valkey operator: priorityClassName support so cache pods survive scheduling pressure\, and an e2e test verifying failover when a primary receives SIGTERM. \n \n This talk is the field guide I wish I'd had. Concretely: how to pick a first issue maintainers actually want fixed (mine were an open feature request and a known testing gap)\; setting up a productive dev loop with Kind and the e2e suite\, including the toolchain gotchas that cost me an evening\; reading a controller's reconcile flow well enough to change it safely\; and writing a deterministic e2e test for something as messy as killing a primary and asserting failover. \n \n I'll also share what review taught me: what maintainers pushed back on\, the mistake I made in a review thread (asserting something about the codebase without verifying it\; don't)\, and why small PRs build trust faster than big ones. \n \n If you use Valkey but have never contributed\, this is your on-ramp: a map of the ecosystem's open needs and a realistic first-contribution checklist.
CATEGORIES:CONTRIBUTING
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:b813944cc65c1353b7e76138d38a6244
URL:http://valkeyconf2026.sched.com/event/b813944cc65c1353b7e76138d38a6244
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T151500Z
DTEND:20261005T153500Z
SUMMARY:Closing Keynote: Where is Valkey Going?
DESCRIPTION:\n
CATEGORIES:KEYNOTE SESSIONS
LOCATION:Chamber Hall\, Level 3\, Prague\, Czechia
SEQUENCE:0
UID:573779ac9524d16780dcf3c41fdd2c21
URL:http://valkeyconf2026.sched.com/event/573779ac9524d16780dcf3c41fdd2c21
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20260814T210605Z
DTSTART:20261005T160000Z
DTEND:20261005T173000Z
SUMMARY:Attendee Reception
DESCRIPTION:\n
CATEGORIES:MEALS+BREAKS+SPECIAL EVENTS
LOCATION:Červený Jelen\, Hybernská 1034/5 110 00\, Prague 1 Prague
SEQUENCE:0
UID:8adf38a5472bcc64e3d2c9af6e9bf2f7
URL:http://valkeyconf2026.sched.com/event/8adf38a5472bcc64e3d2c9af6e9bf2f7
END:VEVENT
END:VCALENDAR