While in-memory caching engines may be alien to many, their functionality sits at the core of applications and enterprise processes. A Darwinian tale of sorts has taken place across two and a half years, featuring Valkey, a fork backed by some of the largest companies around, and its progenitor Redis, steered by the company of the same name. At ValkeyConf 2026 in Prague, we charted how Valkey continues to evolve to fit its environment at a steady pace.
Valkey’s origins are a direct consequence of Redis dropping its open-source license in March 2024. Redis partially backtracked in May 2025 by adding AGPLv3 as one of three license options. Backed by AWS, Google Cloud and Oracle, among others, Valkey by contrast is a BSD-licensed fork that, with version 7.2.5, offered a direct drop-in replacement for Redis 7.2.4. Since then, the two have diverged. Redis is seeking to become the context engine for AI agents, broadening into a full data platform. Valkey, meanwhile, remains a specialized tool, and, unlike Redis, is governed by a collective of maintainers with shared interests rather than a single vendor.
At its core, Valkey is an in-memory key-value store. It keeps data in RAM so applications can access it in well under a millisecond, organized into data structures such as strings, hashes, lists, sets and sorted sets rather than rows and tables. That is typically around an order of magnitude faster than a database lookup, which tends to take several milliseconds. Since memory is finite, choosing what to cache and making the most of the available capacity is critical. It is also a problem every cloud provider and enterprise runs into, without much benefit to owning a proprietary solution you then have to maintain on your own. Many IT teams interact with Valkey through ElastiCache or MemoryDB on AWS, Memorystore for Valkey on Google Cloud, OCI Cache inside Oracle’s cloud or some other name via another provider.
“Everybody needs a caching engine. But most people don’t choose where they operate their applications or databases based on the caching engine,” says Kyle Davis, General Manager, Redis-Valkey Ecosystem at Percona.
Don’t build things twice
“It doesn’t really make sense for three independent companies to build the exact same thing when it’s largely a solved data plane problem,” says Madelyn Olson, Principal Engineer at AWS, Valkey co-creator and maintainer. “It makes more sense for us just to work together on one thing and make it good for our end users.”
Specifically, Olson here is referring to vector similarity search, the technique AI applications use to find stored information closest in meaning to a query. Several cloud providers built it separately. AWS added it to MemoryDB for Redis in preview in November 2023, and Google made the same feature generally available for Memorystore for Redis in April 2024. Google later donated its vector search to Valkey, where it became the BSD-licensed valkey-search module. AWS now builds the vector search in its ElastiCache service on that same module.
Competing on the engine itself, it seems, isn’t worth it. Another example: in the absence of an official Kubernetes operator for Valkey, guides in late 2024 pointed users to third-party options, while the likes of SAP and Inditex published operators of their own. The official valkey-io operator, which the project says is nearing general availability, aims to become the common ground. Something similar is under way for authentication. Oracle built its own authentication extension as a Valkey module, and other cloud providers have followed a similar pattern, says Dmitry Polyakovsky, Consulting Member of Technical Staff at Oracle and Lead Engineer on OCI Cache. There is now a conversation about a common module with plugins for each vendor. Most companies don’t want to maintain their own changes long-term, Olson says, so they try to upstream them.
Jacob Murphy, Staff Software Engineer at Google Cloud, Valkey maintainer and Technical Steering Committee (TSC) member, says that making an internal innovation “canonical in some way makes it easy to maintain, and everyone can get the benefit.”
Governance
Organizations have a funny way of producing systems that echo their own structures. This is known as Conway’s Law, cited by Murphy on stage at ValkeyConf. Valkey is decentralized by design, with nine maintainers on the TSC, employed by a range of companies. Changes to this structure require a supermajority, whereas major decisions ‘merely’ need at least five out of nine to agree. A new exception is that proposals may only need two supporters when no pushback arrives within two weeks. This fast-tracks progress.
Nonetheless, Olson freely admits that at the speed of AI innovations, Valkey’s release cadence may not quite be up to par. Its half-yearly releases have prompted some vendors to build their own features before they get integrated, taking advantage of the permissive BSD license. “The community cares a lot more about stability and consistency [than speed of innovation],” she says. “So we will be a little slower on our side to get something merged and stable for the long term, while companies can individually move very fast to build the functionality they need.”
This continues to be an active process. Polyakovsky tells us the Valkey project has been very collaborative. At the Contributor Summit, held the day after ValkeyConf, he planned to propose “certain ideas that we all implemented separately,” arguing they should be built into Valkey “and then we all can avoid maintaining our custom forks.”
The great migration
User adoption is another matter. When Redis changed its licensing, it lost trust among many users. The problem with trust, as the Dutch saying goes, is that it arrives on foot and leaves on horseback. “Redis was seen as a safe choice previously. Now they see it as a risk,” says Davis, who previously worked at Redis. We’re not here to suggest any stance, and we hope to speak to Redis about its side of the story when we get the chance. Still, the writing does seem to be on the wall that Valkey is here to stay. It’s just a question of jumping ship, which we have noted in conversation with attendees is not always as easy as the migration paths online show.
Davis notes caching is often at the very core of applications. You therefore wouldn’t necessarily want to mess with a working feature, even if it comes with large performance gains. Valkey itself is rarely the bottleneck, Davis says; customers aren’t complaining about its performance. Nevertheless, migrating can pay off for those still on Redis 7.2-era versions. For string-heavy workloads, Percona measured 37.5 percent less memory per key on Valkey 9.1 than on version 7.2, the codebase Valkey shares with Redis 7.2.4. In a world where DRAM prices have risen more than 400 percent between early 2024 and 2026, such gains are welcome.
Issues can also spill over from technical to regulatory. “We think changing source code is easy, but organizational dynamics make things incredibly hard,” Davis says. “In a regulated industry, you make a five-line source change. That change takes you half an hour, but getting it approved takes you six months. That’s an exaggeration, but it takes a long time.”
Conclusion: divergence (as well as convergence)
Polyakovsky notes that keeping the two compatible is hard, as the forks inevitably diverge. According to Olson, the core abstractions – the protocol and the end-user API – are what will remain recognizable, even as everything around them changes. Ultimately, the project in itself was proof of diverging goals between Redis and its largest users and outside maintainers. Valkey itself is predominantly a convergence of ideas, where participants don’t compete on the engine and no single company owns it. “Nobody is fighting against memory efficiency,” as Murphy puts it succinctly. “And nobody is fighting against performance improvements.”
Thus, we should expect Valkey to continue as an aggregator of the industry’s best ideas around caching, where small code changes can yield outsized efficiency gains. In the age of AI, where capacity constraints and LLM-driven code push one another further, a focus on maximum utilization is most welcome.