Valkey 9.0 – open-source velocity and the pursuit of real-time resilience

When Redis – the widely used open-source in-memory database — shifted to a proprietary license, a group of its maintainers decided to take a different path. The result was Valkey — an open-source, Linux Foundation–backed key-value database built to preserve community ownership while pushing performance forward. Eighteen months on, Valkey 9.0 marks the project’s second major release and a confident step toward greater scalability, efficiency, and reliability in real-time data systems.

Maintainer and AWS Principal Software Engineer Madelyn Olson says the team’s goal from the outset has been to build “the most reliable, the fastest sort of caching — a high-performance database for key-value data workloads.” Version 9.0 delivers on that vision with new features that improve scalability, memory control, and cluster reliability — all while keeping the project’s open, community-led ethos intact.

From fork to force

Olson traces the project’s origins to that pivotal licensing change. She explains:

Me and the other Redis maintainer worked with the Linux Foundation to create the Valkey project. We pulled a bunch of other committers from Redis … and we kept the same very permissive license.

That move established Valkey’s independent identity as an open, BSD-licensed, community-led data store focused on performance and resilience. To guide its evolution, the project works to strengthen five core pillars — performance, efficiency, reliability, security, and ease of use.

Valkey 8.0, launched at last year’s Open Source Summit Europe, tripled engine speed through asynchronous I/O and memory prefetching. A second release earlier this year added native JSON and vector similarity search — both crucial for AI-driven workloads. Valkey 9.0 now continues that momentum with three new capabilities designed to improve scalability and operational simplicity.

Fine-grained expiration – smarter memory, less waste

The first new feature is hash-field expiration, which introduces fine-grained time-to-live control for individual fields within a hash. Developers no longer need to expire an entire object when only part of it has gone stale. Olson uses a gaming analogy to illustrate the impact, saying:

There are a lot of interesting video-game use cases…like who’s in a lobby. You might have a top-level key for the game, and individual fields for players. Each one can now have a different time to live, and once that’s expired, you kick that one out.

This more granular control reduces compute overhead, stabilizes memory usage, and makes in-memory caching more predictable — small technical shifts that, at scale, translate into measurable efficiency gains.

Another addition, multiple databases in cluster mode, allows users to run several logical namespaces within one Valkey cluster rather than maintaining multiple clusters for isolation. Olson notes that many organizations wanted a simpler option, commenting:

End users just want to have one, because it’s much simpler to manage… it’s easier to scale a single cluster than a bunch of different clusters.

Each numbered database now acts as a lightweight namespace that adds no overhead when unused. While large-scale operators may still prefer to keep databases separate to avoid “noisy neighbor” effects, the feature brings practical flexibility to smaller or multi-tenant environments such as SaaS platforms or self-hosted community servers.

The new atomic slot migration mechanism addresses one of the most complex challenges in distributed systems — moving data between shards during scaling. Previous versions relied on tooling that could leave clusters in inconsistent states if migrations failed midway.

Olson recalls:

We actually pitched it back in 2019 at RedisConf [the annual conference for the Redis community], but we didn’t build it for four years. It finally came together when engineers from Google joined in and said, ‘We want this to happen.’

The feature uses a snapshot-based process orchestrated directly by the server. While the source and target nodes both stay active, data is streamed incrementally until Valkey performs an atomic handoff — instantly redirecting clients without downtime or data loss. It’s a subtle but major change, turning a formerly fragile manual process into a dependable core capability.

As an in-memory database designed for high-throughput workloads, Valkey continues to chase microsecond gains. Olson explains:

If you actually look at what the bottleneck is in Valkey, it’s the time it takes to fetch the memory from DRAM [Dynamic Random Access Memory].

Version 9.0 improves pipelined command execution by anticipating that bottleneck, she explains: 

We’re basically telling the CPU ahead of time, ‘We’re going to need this memory very shortly, so fetch it ahead of time.’

This pre-fetching approach delivers up to 40% higher throughput with the same hardware. Combined with horizontal scaling improvements, Valkey can now sustain roughly one billion requests per second across a 1,000-node cluster — a theoretical ceiling, but a useful validation of its architecture.

Further optimizations include zero-copy responses for large requests, single instruction, multiple data (SIMD) acceleration for operations such as BITCOUNT, and Multipath TCP support that can cut latency by 25%.

A forward roadmap – durability and multi-tier storage

Looking ahead, Olson says the community’s focus is on extending Valkey beyond ephemeral caching without compromising performance. 

Right now, Valkey is primarily running ephemeral workloads. We’re trying to figure out a way to make the data truly durable and consistent without sacrificing that performance.

Other major roadmap items include SSD tiering, which will allow data to spill over from memory to disk, and active-active replication, enabling writes to any node within a shard for greater availability and architectural simplicity. “Those are the big three things we’re working on,” she says. “But we have a long engineering backlog — lots to do.”

Despite its rapid development cycle, Valkey remains careful with upgrades. The 9.0 release is backward compatible, and thanks to improvements introduced in version 8.1, users can now upgrade or roll back without data loss.

Olson is keen to stress that Valkey’s momentum isn’t being driven solely by major cloud vendors. She emphazises: 

It’s very much a community-driven project. A lot of people learned about it because of the fork from Redis, but since then it’s really evolved to be its own thing.

Contributors from AWS, Google, Alibaba Cloud, Percona, NetApp Instaclustr, and others collaborate under the Linux Foundation’s neutral governance, making Valkey a sustained example of open-source cooperation in a space often dominated by commercial forks.

My take

Valkey 9.0 feels less like a milestone release and more like a sign of steady, confident progress. What stands out isn’t the headline number of a billion requests per second, but how methodically the team continues to remove complexity from distributed systems. Fine-grained expiration, atomic slot migration, and cluster databases may sound incremental, yet they tackle issues that have quietly limited reliability in caching for years.

Madelyn Olson explains these changes with the matter-of-fact precision of someone who knows exactly where the bottlenecks are and how to fix them. It’s that combination of engineering realism and open collaboration that gives Valkey its momentum.

The next stage — adding durability, SSD tiering, and active-active replication — will test how far an open project can go without losing the responsiveness that makes it valuable. But if the team delivers on its roadmap, Valkey may demonstrate that open, community-driven engineering can achieve enterprise-scale performance and reliability without compromise.