En marzo de 2024, Redis Ltd. migró el proyecto desde su licencia permisiva BSD-3-Clause a un modelo de doble licencia que combina la Server Side Public License (SSPL) y la Redis Source Available License v2 (RSALv2). La Open Source Initiative no reconoce la SSPL como una licencia de código abierto, y la RSALv2 incluye restricciones explícitas para empresas que ofrecen Redis como parte de servicios comerciales de caché o streaming. Para los equipos de infraestructura que operan Redis gestionado a escala, esto no era una preocupación legal abstracta: era un problema de adquisición.

Ocho días después de ese anuncio, la Linux Foundation lanzó Valkey: un fork de Redis OSS 7.2.4, con licencia BSD-3-Clause, gobernado por un Comité Técnico de Dirección sin ningún proveedor único al mando. AWS, Google, Oracle, Ericsson y una lista creciente de empresas de nube y código abierto lo respaldaron de inmediato. A principios de 2025, el proyecto contaba con casi 50 empresas contribuidoras, 19.800 estrellas en GitHub y más de 5 millones de descargas en Docker. A mediados de 2026 distribuye la línea 9.1.x mientras mantiene una rama 8.1.x.

Redis Ltd. dio marcha atrás parcialmente en mayo de 2025 cuando Redis 8.0 introdujo AGPLv3 como tercera opción de licencia, impulsado por el regreso del autor original de Redis, Salvatore Sanfilippo. AGPLv3 es una licencia de código abierto reconocida, pero es de copyleft fuerte: cualquier software que interactúe con una instancia de Redis 8 a través de una red puede generar obligaciones de licencia que los equipos legales de bancos, aseguradoras y contratistas de defensa analizarán con detalle. Redis Software 7.2 alcanzó el fin de vida el 28 de febrero de 2026, por lo que el tiempo se agotó en la última versión de Redis con licencia completamente permisiva.

El resultado práctico es que existen dos opciones sólidas y listas para producción: Redis 8.x gestionado bajo su modelo de triple licencia, y Valkey gestionado bajo una licencia que no ha cambiado y que ningún proveedor puede modificar unilateralmente. La decisión entre ambos no se centra principalmente en funcionalidades, sino en el riesgo de gobernanza, la arquitectura de hilos y el coste.

Compatibilidad de protocolo: la historia de la migración es breve

Valkey mantiene compatibilidad total de protocolo de red con Redis. Los clientes RESP2 y RESP3 existentes, los scripts Lua y las topologías de Redis Cluster funcionan sin modificaciones. Para el caché de sesiones en particular, donde las cargas de trabajo están dominadas por operaciones GET, SET, EXPIRE y DEL, la superficie de incompatibilidad es mínima. La ruta de migración desde una instancia de Redis 7.x gestionada a una instancia de Valkey gestionada es, en la mayoría de los casos, un cambio de cadena de conexión seguido de un reinicio progresivo.

Donde conviene hacer una revisión más cuidadosa: los módulos de Redis (RedisSearch, RedisJSON, RedisTimeSeries). Estos son propietarios de Redis Ltd. y no son compatibles con Valkey. El ecosistema de Valkey cuenta con equivalentes comunitarios en desarrollo, pero si tu capa de sesiones está entrelazada con funcionalidades dependientes de módulos, esa dependencia debe resolverse antes de la migración, no durante ella.

Arquitectura de hilos y su impacto en el rendimiento de sesiones

Redis utiliza históricamente un bucle de eventos de un solo hilo para el procesamiento de comandos. Ese modelo es predecible y eficiente en caché, pero limita el rendimiento de una instancia única en hardware moderno con múltiples núcleos. Valkey 8.0 introdujo un modelo de hilos rediseñado que permite operaciones de E/S en paralelo manteniendo la seguridad de los datos. El resultado es un mejor aprovechamiento de las instancias multinúcleo sin necesidad de fragmentación a nivel de aplicación para saturar la CPU disponible.

Para el caché de sesiones, el cuello de botella casi nunca es el cómputo: es la distribución de E/S bajo carga de conexiones concurrentes. El modelo de hilos de E/S de Valkey aborda directamente los casos en que una instancia de Redis de un solo hilo comienza a encolar conexiones en momentos de tráfico pico.

Esto importa especialmente en cargas de trabajo con alta concurrencia de conexiones: tormentas de inicio de sesión, validación de tokens en API gateways o lecturas de sesiones de carrito durante un evento de venta flash. Si tu instancia de Redis gestionada ya tiene un dimensionamiento generoso y la latencia se mantiene dentro del SLA, la diferencia en el modelo de hilos no será perceptible. Si estás escalando horizontalmente para superar los límites de rendimiento de una instancia única, vale la pena comparar la arquitectura de Valkey con tu perfil de tráfico real antes de comprometerte con más fragmentos.

Diferencia de coste en la capa gestionada

La brecha de precios entre Valkey gestionado y Redis gestionado no es marginal. En AWS ElastiCache, las instancias de Valkey basadas en nodos tienen un precio aproximadamente un 20% inferior al de los nodos equivalentes de Redis; el nivel serverless es un 33% más bajo. Google Cloud Memorystore muestra una reducción similar del 20% para Valkey frente a Redis. Samsung Electronics reportó ahorros de infraestructura de aproximadamente el 30% tras migrar a ElastiCache for Valkey a escala global.

Estas cifras son puntuales y cambiarán, pero la tendencia refleja algo estructural: los proveedores de nube no subvencionan Valkey por altruismo. Evitaron la fricción de licencias que habría surgido al distribuir Redis bajo SSPL o RSALv2 como servicio gestionado, y están trasladando parte de ese margen a los clientes. Es de esperar que la brecha persista mientras se mantenga la asimetría de licencias.

Riesgo de gobernanza: la pregunta que Redis gestionado no puede responder del todo

El argumento más sólido a favor de Valkey no es el rendimiento ni el precio: es la gobernanza. El modelo del Comité Técnico de Dirección de la Linux Foundation garantiza que ninguna empresa pueda repetir lo que Redis Ltd. hizo en marzo de 2024. La licencia BSD-3-Clause está fijada a nivel de la fundación. Para los equipos de infraestructura europeos que operan bajo marcos de adquisición que exigen estabilidad en las licencias de código abierto, esa garantía estructural vale más que cualquier benchmark.

La opción AGPLv3 de Redis 8 restaura el reconocimiento de la OSI, pero no restaura la neutralidad de gobernanza. Redis Ltd. mantiene el control del proyecto y puede modificar los términos nuevamente. Los equipos que migraron a Valkey tras el anuncio de 2024 no están siendo paranoicos: están aplicando el razonamiento estándar de riesgo de proveedor a una dependencia que se encuentra en cada ruta de solicitud.

Cuándo Redis 8 gestionado sigue teniendo sentido

Hay razones legítimas para quedarse con Redis gestionado. Si tu stack depende de módulos de Redis sin un equivalente viable en Valkey, el coste de migración puede superar el riesgo de licencia por ahora. Si tu organización tiene un contrato de soporte empresarial vigente con Redis Ltd. que cubre Redis 8, la relación comercial puede ofrecer una indemnización que la vía de código abierto no proporciona. Y si tu equipo legal ha revisado las obligaciones de AGPLv3 y ha concluido que son aceptables para tu topología de red, Redis 8 es un producto técnicamente capaz.

El argumento para quedarse es más estrecho que en 2023, pero no es inexistente. La decisión debe tomarse a partir de un inventario específico de dependencias, no por inercia.

Cómo decidir con confianza: un marco práctico

  • Audita primero las dependencias de módulos. Si usas RedisSearch, RedisJSON o RedisTimeSeries, mapea esas funcionalidades antes de evaluar Valkey. Todo lo demás es sencillo.
  • Haz benchmarks con tu perfil de conexiones real, no con cargas sintéticas. La ventaja de hilos de Valkey se manifiesta bajo E/S de alta concurrencia; las diferencias de latencia en conexión única son despreciables.
  • Ejecuta un entorno paralelo durante al menos dos semanas. Los fallos en el caché de sesiones aparecen con patrones de tráfico real, no en pruebas de carga. Usa feature flags o enrutamiento ponderado para trasladar un porcentaje de sesiones a la nueva instancia antes del corte completo.
  • Fija la versión de tu biblioteca cliente antes de migrar. La mayoría de las bibliotecas cliente de Redis añadieron soporte explícito para Valkey en 2024 y 2025; verifica que tu versión gestiona ambos tipos de servidor correctamente.
  • Calcula el precio según el nivel gestionado que realmente necesitas. El precio serverless es atractivo para cargas de trabajo variables; el precio basado en nodos es más conveniente para volúmenes de sesión sostenidos y predecibles.

Gestionamos instancias de Redis y Valkey para clientes de finanzas, salud y comercio electrónico a través de la oferta de caché gestionado de DIVERSITY, y el patrón que observamos de forma consistente es que los equipos que ejecutan caché de sesiones como carga de trabajo de clave-valor pura (sin módulos, sin pipelines con Lua intensivo) migran a Valkey en una única ventana de mantenimiento sin cambios en la aplicación. Los compromisos de IT Consulting que llevan más tiempo son casi siempre auditorías de dependencias de módulos, no la migración en sí.

La decisión entre Redis gestionado y Valkey tiene una respuesta predeterminada clara para la mayoría de los nuevos despliegues en 2026: empieza con Valkey, mantén la garantía BSD-3-Clause y destina el ahorro en costes a capacidad en lugar de a negociaciones de licencias. La única razón para elegir de otro modo es una dependencia técnica específica que Valkey aún no cubre, y esa lista se reduce con cada nueva versión.