Since Redis changed its licence in 2024, many teams have looked at Valkey — the open-source fork hosted by the Linux Foundation — as a drop-in replacement. For simple setups the move is easy. For larger ones there has been a practical blocker: no standard open-source proxy to put in front of a Valkey cluster. On 22 October 2026 Percona announced Valkey-proxy to fill exactly that gap.
Why the proxy matters
A single Redis or Valkey server is simple for applications to use. A cluster, which spreads data across several nodes, needs cluster-aware client libraries that understand how keys map to nodes, handle redirects and re-discover the topology after a failover. Many older applications, and some client libraries, assume a single server.
Commercial Redis offerings and some cloud services hide this behind their own proxy layer, so the application still sees one endpoint. Open-source Valkey users have had no equivalent — which made moving off commercial Redis a code change, not just an infrastructure change.
What Valkey-proxy does
According to the announcement:
- It sits between applications and Valkey, so that a horizontally scaled cluster looks like a single, standalone server. Applications written for one instance can use a cluster without changing client code.
- It pools backend connections, keeping the number of connections to Valkey bounded as the number of application instances grows.
- It is released under the BSD-3-Clause licence and has been accepted as an official Valkey project.
- The code was planned for release in mid-October, followed by a public testing period; general availability is targeted for early 2027.
In other words: interesting now, production-ready later. It is a good time to start planning and testing, not to put it in front of your payment flow next week.
Before migrating anything, find out what Redis is actually doing for you. In many systems it started as a cache and quietly became a queue, a session store, a rate limiter and a lock service. A cache can be cold-started on the new system; a queue or a session store cannot lose data.
A practical migration plan
- Inventory usage. List every application that connects, which data structures and commands it uses, and whether the data is disposable (cache) or must survive (queues, sessions, counters).
- Check versions and features. Valkey is compatible with the Redis open-source line up to 7.2. Features added only to newer commercial Redis versions or proprietary modules need a replacement or a design change.
- Check persistence and replication settings. Carry over your RDB/AOF and memory eviction configuration deliberately rather than relying on defaults.
- Choose the cutover method. Disposable caches can switch with a configuration change and a warm-up. Data that must survive can be moved by making Valkey a replica of the existing server, or with a dual-write period, followed by a short controlled switchover.
- Load-test before switching. Measure latency at your peak request rate, including after a node failure.
- Keep the old system available for a rollback window until the new one has run through a full business cycle.
Is it worth it?
For teams paying for commercial Redis mainly to get clustering and a single endpoint, Valkey-proxy could remove the reason to keep paying. For teams on a managed cloud cache, the provider's Valkey option is often cheaper than its Redis equivalent — a saving similar to the ones we describe in reducing AWS RDS and Aurora costs. And for small single-server setups, the move has already been straightforward for some time.
Key takeaways
- Valkey-proxy lets applications use a Valkey cluster as if it were one server, with no client code changes.
- It is open source (BSD-3-Clause), an official Valkey project, with general availability targeted for early 2027.
- Start with an inventory: caches are easy to move, queues and sessions need a no-data-loss plan.
- Test under peak load and keep a rollback path until the new setup has proven itself.