Valkey-Proxy: Percona Targets the Last Redis Migration Blocker

The hardest part of leaving Redis for Valkey was never the license or the data. It is the application code that assumes it is talking to one Redis instance. Managed services hide that problem behind a proxy, but teams running Valkey themselves have had no open source equivalent. Percona is now trying to fill the gap, and the timeline puts general availability in early 2027.

What Happened

Percona is building Valkey-proxy, an open source proxy that lets existing applications connect to a Valkey Cluster without being rewritten, The New Stack reports. Percona received approval in late September for the proxy to become part of the Valkey project and is moving the code from private repositories into the public one.

The published schedule: all source code public by the end of October, a release candidate in December, and general availability by early 2027. Freshworks is working with Percona as an early user and design partner, testing the proxy against its own applications to surface edge cases.

Why It Matters

Valkey launched as a Linux Foundation fork within days of Redis dropping its BSD license in 2024. Redis later added AGPLv3 as an option in 2025, but Valkey had already built momentum with backers including AWS, Google Cloud, Oracle, and Percona.

The remaining blocker is architectural. Many applications were written to treat Redis as a single instance. Moving them to a distributed Valkey Cluster can mean changing code to handle multiple nodes, key routing, and differences in how some commands behave across shards. “Right now there’s not really any good open source solution for this,” Kyle Davis, Percona’s general manager for the Redis/Valkey ecosystem, told The New Stack. Davis says Envoy, the most common alternative, does not fully understand the Valkey protocol and cannot support everything Valkey can do.

Percona’s own cluster migration guide shows the other half of the problem. Moving data is a solved, if careful, process: add Valkey nodes as replicas, let them sync, then promote them and retire the Redis primaries. Moving the application layer has had no clean answer outside commercial products.

What This Means for Builders

Davis expects hyperscalers to contribute only “potentially,” because they tend to build proxy tooling tied to their own managed services. That makes Valkey-proxy most relevant to teams that run their own data infrastructure: on-premises clusters, regulated financial services shops with strict data residency rules, and smaller organizations that self-host to control cost.

There is also a longer-term design angle. Davis describes the proxy as “a decoupling layer that in the future we can build other components into.” For platform teams, a proxy between applications and the data tier is a natural place to add connection pooling, observability, and access control, the same pattern service meshes brought to HTTP traffic. For the availability side of running distributed data tiers yourself, see Stack Archive’s breakdown of the quorum math behind multi-cluster Kubernetes databases.

Source: The New Stack

Content created with AI assistance and reviewed for accuracy.