Valkey 9 GA: qué significa el fork de caché, 18 meses después de la separación de Redis, para los equipos ops en DACH

La comunidad Valkey publicó la versión 9 el 14 de abril de 2026 – 18 meses después del fork de Redis 7.4 bajo el paraguas de la Linux Foundation. Con ello, Valkey se presenta por primera vez con un histórico de releases propio que, en contenido, va más allá de la pura compatibilidad con Redis. La pregunta para los equipos ops en DACH ya no es si se migra, sino cuándo y en qué orden.

RelacionadoCloud Repatriation 2026: el modelo TCO  /  Canal Broadcom-VMware: el panorama de providers 2026

Qué aporta Valkey 9 en concreto

El release trae tres categorías de cambios. Nuevas funciones: transporte RDMA para replicación de clústeres en escenarios de alto throughput, gestión mejorada de ACL con integración en Active Directory y una interfaz de scripting renovada que acepta scripts Lua sin breaking changes. Bajo el capó: I/O threading más eficiente que, en benchmarks de la Linux Foundation, muestra en cargas de trabajo read-heavy en torno a un 20 por ciento de ganancia de throughput frente a Redis 7.4. Por último, limpieza de licencias: todo bajo BSD-3, sin cláusulas SSPL.

En el entorno enterprise DACH hay dos puntos relevantes. Primero, la licencia BSD: permite casos de uso en los que la SSPL de Redis 8 habría bloqueado las aprobaciones internas – por ejemplo, en sectores altamente regulados como la banca y la sanidad. Segundo, la disponibilidad gestionada en AWS: ElastiCache for Valkey aporta hasta un 33 por ciento de ventaja de precio frente a ElastiCache for Redis OSS. En equipos con clústeres de caché de varias decenas de nodos, eso se traduce rápidamente en ahorros anuales de cinco cifras.

Valkey 9 frente a Redis 8 en comparación

Ambos stacks coexisten en 2026. Quien tenga que decidir entre ellos rara vez lo hace por razones técnicas – casi siempre es una cuestión de licencia y comercial. Las diferencias de un vistazo:

Qué cuesta la migración en la práctica

Para los clústeres Redis existentes, pasarse a Valkey es en la mayoría de los casos un ejercicio de rolling replacement. Los datos siguen siendo compatibles, los ficheros de persistencia (RDB, AOF) se pueden seguir usando sin exportar/importar. En la práctica eso significa: reconfigurar la topología de replicación, cambiar nodo a nodo, dejar la configuración del cliente tal cual. El esfuerzo para un setup típico de 3 nodos está en el rango medio de pocos días-persona; el trabajo real está en la reestructuración de la monitorización y las reglas de alerta, que esperan nombres de métricas específicos de Redis.

La decisión interesante ya no es Valkey contra Redis. Es Valkey contra las funciones de Redis Stack que, deliberadamente, no se están replicando en la versión OSS. Quien use Bloom filters, grafos o timeseries tiene que evaluar qué módulos Valkey o alternativas encajan.

El punto en el que la cosa se pone incómoda son los módulos comerciales de Redis Stack: RedisGraph, RedisTimeSeries, RedisBloom y RediSearch. Quien los use en producción encuentra hoy en Valkey o bien alternativas de comunidad con distinto grado de madurez, o tiene que pasarse a servicios externos. La Linux Foundation ha anunciado que los Valkey Modules construirán un ecosistema de extensiones estable hasta el Q3 de 2026 – hasta entonces, migrar estos casos de uso es el verdadero proyecto, y no el cambio de caché en sí.

Para quién merece la pena el cambio

Tres grupos tienen en 2026 un business case claro. Primero, empresas de sectores regulados donde la licencia SSPL frena las aprobaciones internas de OSS: bancos, aseguradoras, sanidad e infraestructura crítica. Segundo, clientes AWS con clústeres de caché grandes, donde el 33 por ciento de ventaja de precio se vuelve material. Tercero, equipos que desarrollan desde el ecosistema open source y dependen del soporte de comunidad a largo plazo.

Para el resto vale: la migración no es una urgencia. Quien opere Redis 7.2 o 7.4 en un setup estable gestionado no tiene por qué saltar de inmediato. El momento adecuado es la próxima reforma mayor de infraestructura o la siguiente ventana de renegociación del contrato con el proveedor cloud. Valkey 9 está disponible ahora – pero montar una operación paralela completa solo por probar raramente compensa el esfuerzo.

Preguntas frecuentes

¿Mi cliente Redis actual funciona contra Valkey 9 sin cambios?

Sí, siempre que el cliente no dependa de extensiones de Redis 8. El wire-protocol es idéntico, los comandos estándar son retrocompatibles. En Spring Data, Node-Redis, redis-py, go-redis y Jedis el cambio es sin modificar código – solo la connection URL apunta a otro sitio.

¿Qué pasa con RedisSearch, RedisGraph, RedisTimeSeries y RedisBloom?

Estos módulos del stack son propiedad de Redis Inc. y no funcionan en Valkey. La Linux Foundation trabaja en Valkey Modules para Vector, Search y TimeSeries – el grado de madurez varía. Quien dependa en producción de esos módulos debería planificar la migración como un subproyecto propio, no como un simple cambio de caché.

¿Compensa financieramente AWS ElastiCache for Valkey de verdad?

En cachés pequeños single-node el importe absoluto es manejable. La ventaja de precio del 33 por ciento se vuelve material en clústeres multi-AZ con varias instancias r7g o r7gd. Un clúster típico de 6 nodos con r7g.large ahorra al año una cifra baja de cinco dígitos – suficiente para justificar una migración interna.

¿Hay argumentos de compliance a favor de Valkey en auditorías DACH?

Sí. BSD-3 es open source conforme a OSI, la SSPL de Redis 8 no. En los comités internos de OSS de bancos, aseguradoras y administraciones, Redis 8 cae por el filtro SSPL y Valkey lo pasa. Quien dependa de una política interna de OSS tiene con Valkey menos necesidad de discusión.

Fuente de la imagen de portada: Pexels / panumas nikhomkhai (px:1148820)