Valkey-proxy: migrate from Redis without rewriting your app

When Redis changed its license in 2024, moving away from the permissive BSD to proprietary models, the community reacted quickly. Within days, the Linux Foundation launched Valkey, an open source fork with independent governance. Redis later rectified this by adding AGPLv3 as an option in 2025, but by then Valkey had already taken its own path for those seeking a permissive license and a project without dependence on a single vendor.

Since then, Valkey has reduced its memory requirements, incorporated new cluster management and access control features, and started using AI agents for maintenance tasks such as backporting fixes. However, for many organizations, a significant obstacle remained before making the leap.

The proxy problem: applications that expect a single instance

Redis is a widely used in-memory data store for caching and workloads where speed is critical. Many applications were built assuming they were talking to a single instance. Migrating those applications to a distributed Valkey cluster involves modifying code to handle multiple nodes, routing, and differences in the behavior of certain commands.

Commercial Redis products and some cloud services solve this with proxy layers between the application and the cluster. But companies that want to operate Valkey on their own did not have an equivalent alternative. That is the gap Percona aims to fill with Valkey-proxy, an open source proxy that allows existing applications to connect to a Valkey cluster without rewriting.

Percona, an open source database software and services company that supports MySQL, PostgreSQL, and MongoDB, is one of the organizations supporting Valkey alongside AWS, Google Cloud, and Oracle. In an interview at the Linux Foundation's Open Source Summit Europe in Prague, Kyle Davis, head of the Redis/Valkey ecosystem at Percona, noted that having to rewrite applications before moving to clustered Valkey deployments is one of the last major blockers to broader adoption. "Right now there isn't really a good open source solution for this, and this gap has existed," he said.

Davis acknowledges that there are other proxies, such as Envoy, but argues that it does not fully understand the Valkey protocol and manages connections in a way that does not support everything Valkey can do. That leaves some companies stuck between legacy applications built around a single Redis instance and the clustered Valkey deployments they would need as they grow.

What it means for an SMB or an IT team

For an SMB, the relevant question is not so much the Redis license as how much it would cost to move an application into production. If your application uses Redis as a cache or as a session store and is written for a single instance, migrating to a Valkey cluster could involve weeks of development and testing. A proxy that absorbs that complexity changes the calculation: you reduce the risk of migration and can postpone rewriting the code.

Context must be taken into account. Valkey-proxy is under development: Percona received approval in late September for the project to become part of Valkey, and is moving the code from private repositories to the public project. The goal is for all source code to be publicly available by the end of October, followed by a release candidate in December and general availability in early 2027. Freshworks will be one of the first to test it as an early user and design partner.

In other words, it is not a technology to adopt tomorrow in critical production. But it is time to plan.

What we recommend at ForgeNEX

1. Inventory your Redis uses. Not all services need a cluster. Separate those that are pure cache from those that store state or data with consistency requirements.
2. Identify which applications assume a single instance. Those are the natural candidates for a proxy when Valkey-proxy matures.
3. Do not improvise data migration. A proxy solves the connection layer, but the replication, failover, and backup strategy is still yours.
4. Monitor the project timeline. If your roadmap includes moving away from Redis in 2026-2027, the December release candidate is a good window for controlled testing.
5. Review the proxy's security. Any intermediate layer that handles credentials and connections is a point that must be hardened. As we discussed in the risk of credentials inherited by AI agents, intermediate layers concentrate privileges and deserve specific attention.

Davis also notes that the proxy could give Valkey a place to add other capabilities over time: "it provides a decoupling layer on which we can build other components in the future." That flexibility is interesting, but it also means it is advisable to follow the project's evolution before committing.

In summary: Valkey-proxy is not a silver bullet or an immediate solution, but it removes one of the most repeated arguments for not moving away from Redis. For IT teams with limited resources, that is exactly the kind of piece that was missing to propose a realistic migration.

Source: The New Stack. Analysis and adaptation: ForgeNEX.