Valkey-proxy: migrar de Redis sin reescribir tu app

Cuando Redis cambió su licencia en 2024, dejando atrás la permisiva BSD por modelos propietarios, la comunidad reaccionó rápido. En pocos días, la Linux Foundation puso en marcha Valkey, un fork open source con gobernanza independiente. Redis rectificó después añadiendo AGPLv3 como opción en 2025, pero para entonces Valkey ya había tomado su propio camino para quienes buscan una licencia permisiva y un proyecto sin dependencia de un único proveedor.

Desde entonces, Valkey ha reducido sus requisitos de memoria, ha incorporado nuevas funciones de gestión de clústeres y control de acceso, y ha empezado a usar agentes de IA para tareas de mantenimiento como el backporting de correcciones. Sin embargo, para muchas organizaciones quedaba un obstáculo importante antes de dar el salto.

El problema del proxy: aplicaciones que esperan una sola instancia

Redis es un almacén de datos en memoria muy extendido para caché y cargas donde la velocidad es crítica. Muchas aplicaciones se construyeron asumiendo que hablaban con una instancia única. Migrar esas aplicaciones a un clúster Valkey distribuido implica tocar código para gestionar múltiples nodos, enrutamiento y diferencias en el comportamiento de ciertos comandos.

Los productos comerciales de Redis y algunos servicios cloud resuelven esto con capas proxy entre la aplicación y el clúster. Pero las empresas que quieren operar Valkey por su cuenta no tenían una alternativa equivalente. Ese es el hueco que Percona quiere cubrir con Valkey-proxy, un proxy open source que permite a las aplicaciones existentes conectarse a un clúster Valkey sin reescribirse.

Percona, compañía de software y servicios de bases de datos open source que respalda MySQL, PostgreSQL y MongoDB, es una de las organizaciones que apoyan Valkey junto a AWS, Google Cloud y Oracle. En una entrevista en el Open Source Summit Europe de la Linux Foundation en Praga, Kyle Davis, responsable del ecosistema Redis/Valkey en Percona, señaló que tener que reescribir aplicaciones antes de moverse a despliegues Valkey en clúster es uno de los últimos grandes bloqueadores para una adopción más amplia. «Ahora mismo no hay realmente una buena solución open source para esto, y ha existido este hueco», indicó.

Davis reconoce que hay otros proxies, como Envoy, pero sostiene que no entiende por completo el protocolo de Valkey y gestiona las conexiones de una forma que no soporta todo lo que Valkey puede hacer. Eso deja a algunas empresas atrapadas entre aplicaciones antiguas construidas alrededor de una instancia Redis única y los despliegues Valkey en clúster que necesitarían a medida que crecen.

Qué significa para una pyme o un equipo de IT

Para una pyme, la pregunta relevante no es tanto la licencia de Redis como cuánto costaría mover una aplicación en producción. Si tu aplicación usa Redis como caché o como almacén de sesiones y está escrita para una instancia única, migrar a un clúster Valkey podía implicar semanas de desarrollo y pruebas. Un proxy que absorbe esa complejidad cambia el cálculo: reduces el riesgo de la migración y puedes posponer la reescritura del código.

Hay que tener en cuenta el contexto. Valkey-proxy está en desarrollo: Percona recibió la aprobación a finales de septiembre para que el proyecto pase a formar parte de Valkey, y está moviendo el código de repositorios privados al proyecto público. El objetivo es que todo el código fuente esté disponible públicamente a finales de octubre, seguido de un release candidate en diciembre y disponibilidad general a principios de 2027. Freshworks será uno de los primeros en probarlo como usuario temprano y socio de diseño.

Es decir, no es una tecnología para adoptar mañana en producción crítica. Pero sí es el momento de planificar.

Qué recomendamos desde ForgeNEX

1. Inventaria tus usos de Redis. No todos los servicios necesitan un clúster. Separa los que son caché pura de los que guardan estado o datos con requisitos de consistencia.
2. Identifica qué aplicaciones asumen una instancia única. Esas son las candidatas naturales a un proxy cuando Valkey-proxy madure.
3. No improvises la migración de datos. Un proxy resuelve la capa de conexión, pero la estrategia de replicación, failover y respaldo sigue siendo tuya.
4. Vigila el calendario del proyecto. Si tu hoja de ruta incluye salir de Redis en 2026-2027, el release candidate de diciembre es una buena ventana para pruebas controladas.
5. Revisa la seguridad del proxy. Cualquier capa intermedia que maneja credenciales y conexiones es un punto que hay que endurecer. Como comentamos en el riesgo de credenciales heredadas por agentes de IA, las capas intermedias concentran privilegios y merecen atención específica.

Davis apunta además que el proxy podría dar a Valkey un lugar donde añadir otras capacidades con el tiempo: «proporciona una capa de desacoplamiento en la que en el futuro podemos construir otros componentes». Esa flexibilidad es interesante, pero también significa que conviene seguir la evolución del proyecto antes de comprometerse.

En resumen: Valkey-proxy no es una bala de plata ni una solución inmediata, pero elimina uno de los argumentos más repetidos para no moverse de Redis. Para equipos de IT con recursos limitados, eso es exactamente el tipo de pieza que faltaba para plantear una migración realista.

Fuente: The New Stack. Análisis y adaptación: ForgeNEX.