A conference speaker spotlight interview with Madelyn Olson, Valkey co-creator and AWS Principal Software Engineer, previewing her P99 CONF talk on the vertical scaling wall and how Valkey addresses it through both scale-up and scale-out approaches. She discusses ongoing work on data tiering in Valkey to offload from DRAM to NVMe storage, driven by AI inference KV caching workloads and DRAM cost pressures. She also mentions recent internal rewrites — replacing a skiplist-based ordered index with a B+ tree and rebuilding the main hashtable as a Swiss table — and recommends reading design discussions in real open source codebases to learn about performance tradeoffs.
Table of contents
How do you answer the dreaded “tell us about yourself” question?What’s the most interesting project that you’re working on right now, or hoping to start soon?What will you be talking about at P99 CONF?What other P99 CONF talks are you most looking forward to, and why?Any performance-related resource recommendations for the P99 CONF community?Questions this post answers
Why is Valkey keeping command execution single-threaded instead of moving to multi-threaded execution?
Command execution remains single threaded in Valkey for now as a deliberate design choice discussed alongside the broader vertical versus horizontal scaling tradeoff. The reasoning ties into how Valkey benchmarks scaling decisions and which metrics it recommends scaling on, rather than assuming more cores automatically means better throughput for this workload shape. Developers weighing threading models for in-memory data stores can follow this reasoning via daily.dev.
What is data tiering in Valkey and why is it being built now?
Data tiering in Valkey moves data between DRAM and NVMe storage instead of keeping everything DRAM-only, a design decision baked in since Valkey's beginning. It is being revisited now because NVMe latency keeps dropping and bandwidth keeps climbing, DRAM is the biggest cost driver in Valkey deployments, and AI inference KV caching workloads demand extreme throughput and capacity that pure DRAM struggles to deliver cost-effectively. Teams evaluating memory versus storage tradeoffs in caching layers can track this work through daily.dev.
What internal data structure changes has Valkey made recently to improve performance?
Valkey replaced its original skiplist-based ordered index, which had existed since the project began, with a B+ tree, and rebuilt its main hashtable as a Swiss table. Both changes took established designs and adapted them to Valkey's specific constraints of being memory hungry while avoiding latency stalls, since a cache that times out defeats its purpose. Engineers curious about real-world data structure tradeoffs in caches can explore Valkey's design work via daily.dev.
12.3K Impressions1 Comment