By ByteBot
On October 7, Percona announced Valkey-proxy: an open source proxy layer, now accepted as an official project under the Valkey umbrella, that lets an application talk to a Valkey cluster as if it were a single standalone node. If you have been watching the Redis-to-Valkey migration story unfold over the past two years, you know what this means. The last credible technical excuse for staying on Redis just got a lot weaker.
The Cluster Migration Wall
The Valkey momentum is real. Eighty-three percent of enterprises have adopted or are actively testing Valkey, AWS and GCP both default new deployments to it, and Snap cut $1.26M per year simply by moving off Redis. Valkey itself has been maturing rapidly — 9.2 brought a forkless persistence path and 9.1 cut memory usage 10% without a config change. And yet a non-trivial segment of teams has been stuck — not because they prefer Redis, but because their applications were built for a standalone node and rewriting for cluster mode is expensive work.
Cluster mode breaks things that standalone mode handles transparently. Multi-key commands like MGET, MSET, and DEL fail with a CROSSSLOT error when the keys hash to different shards. SCAN and KEYS behave per-node with no unified cursor. Pub/sub messages do not propagate across shards. Every one of those patterns requires the application to be aware of the cluster topology — exactly the kind of infrastructure logic that belongs in a proxy, not in business code.
What Valkey-proxy Actually Does
Valkey-proxy sits between the application and the cluster, presenting all nodes as a single endpoint. Single-key commands are routed by CRC16 hash to the correct shard with no client-side logic. Multi-key commands — MGET, MSET, MSETEX, DEL, UNLINK, EXISTS, TOUCH, LCS, and module commands like JSON.MGET and JSON.MSET — are split per shard, dispatched in parallel, and merged back into a single correctly-ordered response before the application ever sees it. Cluster-wide commands such as DBSIZE, SCAN (with cursor reassembly), KEYS, and FT.* search-index commands are broadcast to every primary node with results merged.
The connection architecture is designed for scale. Each worker thread runs its own event loop and maintains per-command-class connection pools to each backend node — separate pools for normal traffic, blocking commands, pub/sub, transactions, and ACL operations. That means application instances multiplex through the proxy rather than each opening its own connections per shard, which matters considerably in high-concurrency and serverless environments where connection count is a real constraint.
Timeline and What to Watch
The code is not public yet. Percona plans to release it under BSD-3-Clause by end of October, followed by a release candidate in December and general availability in early 2027. Critically, this is not a third-party tool that may or may not be maintained — it has been accepted as an official project under the Valkey organization, which means it carries the same governance and community backing as Valkey itself.
The timing is deliberate. ValkeyConf 2026 ran in Prague on October 5, and Percona dropped this announcement two days later. The Valkey ecosystem is building toward enterprise-grade completeness, and a cluster proxy has been the most-cited missing piece. Once the GA lands, the migration calculus for large teams shifts substantially. The New Stack’s analysis frames it as Percona targeting “the last major hurdle to Valkey adoption” — and that description holds up.
What to Do Before the Code Drops
If you are running Valkey or Redis in standalone mode and have cluster migration anywhere on your roadmap, the next few weeks are a good time to prepare:
- Audit your codebase for multi-key commands —
MGET,MSET,DELwith multiple keys, pipeline batches that cross key namespaces. - Check how your application uses
SCANandKEYS. If you rely on full keyspace iteration, understand that the proxy will handle this for you, but your cursor logic may need adjustment. - Identify any pub/sub dependencies. The proxy handles this via a dedicated connection pool, but verify your specific use case when the docs drop.
- Watch the Valkey GitHub organization for the public release at end of October. The December RC is the right time to test against your production workloads.
The Redis license change was a forcing function two years ago. Valkey has spent those two years closing every gap. A cluster-transparent proxy was the last significant one, and it is now on a concrete timeline. If you have been waiting for a reason to start the migration planning conversation, 83% of enterprises already have. This is it.
