> ## Content Index > Fetch the complete content index at: https://debugly.dev/llms.txt > Use this file to discover other available public pages before exploring further. # Valkey-proxy: Migrating Redis Without the Rewrite - URL: https://debugly.dev/valkey-proxy-redis-without-the-rewrite/ - Published: 2026-10-10T15:00:00.000Z - Updated: 2026-10-10T15:00:00.000Z - Description: Percona's Valkey-proxy lets old Redis clients talk to clustered Valkey without a rewrite, moving the migration risk from your code to a layer you can test. - Author: Rohit Bhadani - Tags: DevOps, Performance Between the rewrite and the point sit 6 quiet assumptions, and the incident is the story of one of them failing. Since Redis changed its licensing in 2024 and Valkey forked away under the Linux Foundation, the argument for moving has been settled for most teams. The argument against was never the server. It was the client code. Percona's Valkey-proxy, announced on 7 October and set to be donated to the Valkey project with public code by the end of October, is aimed squarely at that against. The reporting here is The New Stack's coverage of Kyle Davis, Percona's general manager for the Redis and Valkey ecosystem, plus Percona's own announcement, both from the first week of October. ## The hurdle was never the server Standalone Valkey speaks almost exactly the dialect your application already speaks, which is why small migrations are uneventful. The trouble starts at cluster mode. A clustered deployment answers a request with a redirect when the key lives on another shard, and a correct client catches that redirect, learns the slot map, and retries against the right node. Old clients, thin wrappers and a long tail of libraries never learned that dance, because they were written against a single instance that never redirected. So growing into a cluster meant rewriting the data layer first, and the rewrite is the expensive thing: every code path that touches the cache, tested again, for a change that brings no feature. Commercial Redis and the big cloud providers solved this with proprietary proxies that absorb the topology, so the client stays naive and the proxy does the cluster talk. The open source side had no equivalent. Davis points at Envoy, but notes it does not fully understand the Valkey protocol and handles connections in a way that caps what it can support. Valkey-proxy is the missing middle: an open layer that lets an application built for one Redis behave correctly against a clustered Valkey. ## What a proxy can and cannot hide A proxy fixes the topology problem, and it is real that most workloads will slide across without code changes, as Percona claims and as Freshworks, the named early design partner, is testing. But a compatibility layer moves the risk rather than deleting it, and the honest migration checklist is the list of things a proxy struggles to hide. Transactions that touch keys on different slots. Lua scripts that assume every key is local. Blocking commands held open across a moving topology. Pub/sub, where the subscription lives on a connection the proxy must now route. Cursor based scans, whose cursor encodes a node's private view of the keyspace. Hash tags that your code never used because it never needed to. Each of these is fine against a single instance and strange against a cluster, with or without a proxy in front. That list is also the test plan: run your real command mix against the proxy in staging and read the failures as a map, because every failure is a place where the assumption of one server is still in your code. It is the same discipline as [the cache stampede that hit the database the second the key expired](https://debugly.dev/cache-stampede-after-key-expiry/), where the migration changed one layer and the failure surfaced two layers away. ## The lock-in math that drives this The technical story is only half of it. The migration wave exists because licensing made staying expensive, and the proxy matters because rewriting made leaving expensive. Analyst coverage of the announcement, including ECI Research survey figures cited by Efficiently Connected, puts roughly half of organisations in the camp that tracks vendor lock-in as a risk while still choosing on functionality, and about a quarter in the camp so wary of lock-in that they will only adopt open and portable tooling. Valkey-proxy is aimed at both: the first group gets a cheaper exit, the second gets an exit that never touches their application code. The same coverage makes the sharper claim that the proxy is the product, because Valkey's capabilities were never the objection; the porting tax was. If that holds, expect compatibility shims to become a genre, with other open data stores shipping their own Redis dialect layers, and expect a managed service to appear around this one. Plan as if the proxy category is permanent, because the code you write against it will outlive whichever vendor wins. ## The proxy is now your infrastructure One operational truth deserves its own paragraph: the proxy sits on the hot path of every cached read, so its p99 is your p99, and its restart is your outage. Run it beside the application rather than as a distant tier, watch its tail latencies per command, and rehearse its failure the way you rehearse [the CDN that answered the health check instead of the app](https://debugly.dev/cdn-answered-the-health-check/), where a healthy-looking layer in front hid an unhealthy one behind. A compatibility layer you have not failed on purpose is a compatibility layer you have not met. ## An order that works Move the reads first and keep the old instance authoritative, so a wrong answer from the new stack is visible and free. Compare latency distributions per command, not averages, because a proxy adds a hop and the p99 is where you will feel it. Promote writes only after the stampede behaviour is proven, since the first cold minute after a cutover is the load test you did not plan, as in [why adding one server moved everyone's cache](https://debugly.dev/one-server-moved-every-cache/): placement and routing decisions decide what a migration actually costs. The timeline matters for planning. Code public by the end of October, a release candidate in December, general availability early 2027\. That is a sensible moment to start the staging work now and the production move next year, letting the community find the edge cases in public before your traffic does. ## What I now do A compatibility proxy turns a rewrite project into a testing project, which is cheaper, but it trades risk in your code for trust in a layer, so the migration plan is the list of behaviours the proxy cannot fake: cross-slot transactions, Lua locality, blocking calls, pub/sub routing and scan cursors, tested against your real command mix before any write traffic moves. Valkey-proxy removes the last structural excuse for staying on licensed Redis by letting naive clients speak to a real cluster, and the teams that migrate smoothly will be the ones that treated the proxy as a thing to test against, not a thing to believe in.