Can Valkey-proxy move your existing Redis client to a cluster?
Through Valkey-proxy, an MGET across cluster nodes works, while RENAME still fails with CROSSSLOT. Which parts of your app will move to the cluster unchanged?
- Valkey-proxy puts cluster routing behind an endpoint that ordinary single-node clients can use.
- Selected multi-key commands are combined across nodes; transactions and SELECT remain adoption blockers for applications that need them.
- Source and tests are public. Percona’s announced general-availability target is early 2027.
Keeping the client library depends on the commands you use
Valkey-proxy is intended to let an application keep its single-node Redis or Valkey client while accessing a cluster. It finds the node responsible for a key and forwards the request. For MGET, it can split work across nodes and reconstruct the reply in the original key order.
That does not make every standalone application compatible. The current command table marks MULTI, EXEC and WATCH as planned. SELECT is unsupported. Applications using transactions or switching logical databases cannot treat this as a connection-string-only migration.
Percona announced the project on October 7, targeting general availability in early 2027. As of October 26, the repository contains source, build files and integration tests, but no published GitHub release. Public code is available for evaluation; the announced GA date remains a target.
A cluster node redirects a client rather than acting as its proxy
Valkey Cluster assigns keys to hash slots distributed across nodes. Its cluster specification explains that a node receiving a request for somebody else’s slot redirects the client instead of forwarding the command itself.
A cluster-aware client tracks that mapping and handles responses such as MOVED. A client built around one server does not acquire those capabilities merely because its hostname changes.
The proxy moves routing and connection pools outside the application. That can reduce work in each client integration, while adding a proxy that the operations team must run.
Cross-node MGET does not remove every CROSSSLOT constraint
The project’s feature documentation distinguishes commands it splits across nodes from commands that must stay within one slot.
| Application operation | Documented behavior | Migration implication |
|---|---|---|
| MGET | Splits requests and restores the original key order. | Multi-key reads can span nodes. |
| MSETNX, RENAME | Requires all involved keys in one slot. | CROSSSLOT remains possible. |
| EVAL, EVALSHA | Requires the supplied keys in one slot. | Review the key layout used by scripts. |
| MULTI, EXEC, WATCH | Planned. | Existing transaction paths need a separate decision. |
| SELECT | Unsupported. | Database-switching clients need attention. |
Hash tags can place related keys in the same slot, but the proxy does not redesign an application’s key names. Combining replies from several nodes also does not imply a distributed transaction guarantee.
Test application operations, not just PING
Start an evaluation with the commands your application actually sends, including connection initialization, scripts and transaction paths. If the server is also changing from Redis to Valkey, server-version and data-migration compatibility remains a separate requirement.
Even a connection check has a specific limit: the proxy’s feature document says it answers PING locally, without a backend request. A PONG therefore does not establish that the data nodes can serve the application’s reads and writes.
The useful promise is less cluster-specific code in the client. Whether an existing application can make that move depends on preserving the behavior of its actual operations.