6 min de lectura

Valkey 9 procesa más de mil millones de solicitudes por segundo en clúster desde octubre de 2025 y ha reemplazado a Redis como opción predeterminada en los principales servicios gestionados de caché. Tras 18 meses, este fork originado por cuestiones de licencia se ha convertido en un proyecto técnicamente independiente, y Redis 8 solo lo alcanza parcialmente.

Lo más importante en breve

• Velocidad del fork: Ocho días después del anuncio de Redis sobre la licencia SSPL en marzo de 2024, Valkey ya estaba bajo la Linux Foundation, respaldado por AWS, Google, Oracle, Alibaba, Ericsson, Huawei y Tencent (TechCrunch, 2024).
• Valkey 9 GA: Disponible desde el 21 de octubre de 2025. Un clúster gestiona más de 1.000 millones de solicitudes por segundo, y el rendimiento de un nodo individual aumenta hasta un 40 % respecto a Valkey 8.1 (Linux Foundation, 2025).
• Estándar en la nube: AWS ElastiCache y Google Memorystore han adoptado Valkey como opción predeterminada para nuevas instancias. Valkey registra aproximadamente 1 millón de descargas de contenedores por semana (The Stack, febrero de 2026).
• Contraofensiva de Redis 8: En mayo de 2025, Redis Labs lanzó la versión 8 con un modelo de triple licencia (RSALv2, SSPLv1 y AGPLv3), volviendo al código abierto, aunque bajo términos copyleft en lugar de la licencia BSD.
• Migración: Según los mantenedores, el cambio de Redis 7.2 a Valkey es un «seamless patch» (parche sin interrupciones). AWS ofrece actualizaciones in situ sin tiempo de inactividad.

18 meses de Valkey: del fork de protesta al predeterminado

El 20 de marzo de 2024, Redis Labs cambió de la licencia BSD a la Server Side Public License (SSPLv1), una medida dirigida contra los hiperscalers que ofrecían Redis como servicio gestionado sin contribuir al proyecto. Ocho días después, Valkey apareció en GitHub como fork de Redis 7.2.4, con Madelyn Olson (AWS, anteriormente mantenedora de Redis) como figura impulsora y la Linux Foundation como entidad paraguas.

Lo que comenzó como una protesta por la licencia se ha convertido, 18 meses después, en una base de código independiente. Valkey 8.0 introdujo subprocesamiento de E/S a finales de 2024, y Valkey 8.1 mejoró los handshakes TLS en torno a un 300 %. Valkey 9.0 alcanzó la disponibilidad general el 21 de octubre de 2025, con migración atómica de slots, expiración por campo en hashes y soporte para múltiples bases de datos en modo clúster. Ninguna de estas funcionalidades existe en Redis 8 de forma comparable.

«Consideramos crítico mantener la licencia BSD. La mayoría de los usuarios no quieren perderse en los matices de la LGPL o la SSPL; simplemente quieren desarrollar. Queríamos continuar desde donde lo habíamos dejado, sin el riesgo de otro cambio de licencia.»
– Madelyn Olson, ingeniera principal en AWS y mantenedora de Valkey (The Stack, febrero de 2026)

La estructura de respaldo es inusualmente amplia: además de AWS, figuran Google, Oracle, Alibaba, Ericsson, Huawei y Tencent como patrocinadores corporativos en la web de Valkey. Para un proyecto de infraestructura, esta alianza es poco común y marca una clara diferencia respecto a forks dependientes de un único proveedor. Quienes conocen la historia de OpenStack, MariaDB o OpenTofu saben que la gobernanza multivendedor bajo una fundación neutral es el factor más importante para garantizar la estabilidad a largo plazo de un fork. Un único proveedor puede cambiar sus prioridades en cualquier momento, mientras que un consorcio con siete grandes actores tecnológicos cuenta con mecanismos internos de equilibrio y contrapeso.

Además, bajo el capó, el equipo de Valkey ha reestructurado la propiedad del código de forma distinta a como lo hacía Redis bajo su antiguo modelo. Las revisiones se gestionan mediante un comité público de mantenedores, y los parches provienen con frecuencia similar de ingenieros de AWS, Google y Alibaba. Esto no garantiza necesariamente una mayor calidad del código, pero sí ofrece una base más estable frente a decisiones estratégicas unilaterales. Quien en 2024 se preguntaba si un paso como el de la SSPL podría repetirse encuentra en esta estructura de gobernanza la respuesta más clara que ofrece actualmente la industria.

Valkey 9 frente a Redis 8: dónde radican realmente las diferencias

El error más común en este debate es suponer que se trata únicamente de la licencia. Desde octubre de 2025, ambos proyectos han divergido técnicamente, y esas diferencias afectan ya a cargas de trabajo productivas.

Fuentes: valkey.io, redis.io, AWS Database Blog, Google Cloud Blog (2025-2026)

El punto decisivo es la migración atómica de slots. El resharding clásico de clústeres Redis genera breves errores de redirección que, en entornos de alta carga, se traducen en timeouts para los clientes. Valkey 9 traslada los slots sin tiempo de inactividad ni errores para el cliente: una funcionalidad clave, especialmente en clústeres de caché multi-inquilino.

Las cifras tras la disputa de los benchmarks

Ambos proyectos anuncian saltos de rendimiento, y ambas cifras son correctas por sí solas. Redis 8 afirma alcanzar hasta un 87 % más velocidad en comandos y hasta el doble de rendimiento respecto a Redis 7.4. Valkey 9 reporta hasta un 40 % más de rendimiento frente a Valkey 8.1 y, por primera vez, lleva al clúster más allá del umbral de los mil millones.

Quien intente comparar directamente ambas cifras cae en una trampa. Redis 8 se compara con su propia versión anterior, la 7.4, a nivel de nodo individual. Valkey 9 mide la escalabilidad a nivel de clúster. El único punto de comparación fiable son los benchmarks independientes, que hasta ahora confirman la tendencia de Valkey: en el benchmark de MayoCoin, Valkey 8.0.1 logró mayores valores de rendimiento y mejores latencias p99 que Redis 7.1.0 en hardware idéntico.

Para los equipos que deben tomar hoy una decisión, el indicador más relevante no es el porcentaje, sino la velocidad de lanzamiento de nuevas funcionalidades (feature velocity). Valkey ha publicado tres versiones mayores en 18 meses. Redis 8 supuso el regreso a la bandera del código abierto, pero aún no demuestra un ritmo sostenido de lanzamientos.

Detrás de Valkey 9 hay tres innovaciones técnicas que influyen más en los benchmarks que la cifra oficial de rendimiento. El prelectura de memoria (memory prefetching) para comandos en pipeline aporta, según las notas de lanzamiento, un rendimiento hasta un 40 % superior en operaciones agrupadas. Las respuestas sin copia (zero-copy responses) para respuestas grandes reducen hasta un 20 % la sobrecarga, ya que los datos ya no se copian entre el espacio del kernel y el del usuario. Y las optimizaciones SIMD para BITCOUNT e HyperLogLog aceleran determinadas consultas analíticas hasta en un 200 %. Estas tres optimizaciones apuntan precisamente a cargas de trabajo que los usuarios de Redis llevaban años identificando como cuellos de botella: análisis sobre bitfields, agregaciones en tiempo real y pipelines grandes en trabajos por lotes.

Qué están haciendo ahora los proveedores cloud

La curva de adopción más clara la marcan los hiperscalers. AWS lanzó ElastiCache for Valkey ya en 2024, convierte a Valkey en la opción predeterminada para nuevos clústeres y ofrece una ruta gestionada de actualización para instalaciones existentes de Redis. Google Cloud ha declarado Memorystore for Valkey 9.0 como versión GA (disponibilidad general), y Oracle OCI ha lanzado su propio servicio gestionado, OCI Cache. En los tres casos, «Valkey como predeterminado» significa que quien no se oponga explícitamente recibirá Valkey -no Redis-.

Las cifras de adopción respaldan esta tendencia. Según datos recientes de Docker Hub, Valkey registra aproximadamente un millón de descargas de contenedores por semana y supera ya los 70 millones desde el fork. Aunque esta métrica no refleja directamente el uso en producción, sí constituye un indicador sólido de integración en pipelines CI/CD, desarrollo local e implementaciones en Kubernetes. Para un proyecto con apenas 18 meses de vida, esta densidad de integración resulta notable.

Un caso práctico concreto procedente de ElastiCache: la bolsa taiwanesa de criptomonedas MaiCoin realizó una actualización blue-green de Redis OSS a Valkey y comparó bajo carga idéntica Redis 7.1.0, Valkey 7.2.6 y Valkey 8.0.1. El resultado: Valkey 8.0.1 ofreció el mayor rendimiento (throughput), la menor latencia p99 y la mejor eficiencia de memoria. Para cargas de trabajo productivas con requisitos estrictos de latencia, esto no es un juego de cifras publicitarias, sino un argumento tangible relacionado con costes.

El mercado DACH (Alemania, Austria y Suiza) reacciona con mayor cautela, aunque de forma comprensible. Los entornos gestionados de Kubernetes más grandes en AWS Frankfurt y Google Cloud Frankfurt ya despliegan Valkey 9 para nuevos clústeres, mientras que las instalaciones existentes suelen seguir ejecutando Redis 7.x. Este comportamiento sigue el patrón típico en la región DACH: primero se clarifica la cuestión de licencias y luego se planifica la migración en el próximo ciclo de planificación de capacidad -rara vez de forma precipitada, y normalmente coordinada con ramas de lanzamiento o actualizaciones programadas de clústeres-.

Migración: qué significa «parche sin interrupciones» en la práctica

Valkey 9 habla el protocolo de Redis (RESP) y es compatible con clientes de Redis 7.2 sin necesidad de modificaciones. Esta es la razón principal por la que, en muchos casos, la migración se realiza sin cambios en el código. AWS ElastiCache ofrece una ruta gestionada de actualización in situ: los nuevos nodos de Valkey se despliegan dentro del clúster existente, replican desde el nodo primario de Redis y luego se realiza un cambio mediante failover. Tiempo de inactividad: cero.

En la realidad existen tres escollos. En primer lugar: los módulos de Redis Stack, como RedisJSON, RediSearch o RedisBloom, son propietarios y no están incluidos en Valkey. Quienes los utilicen deberán optar bien por los módulos comunitarios de Valkey (Valkey-JSON, Valkey-Search y Valkey-Bloom, todos bajo licencia BSD) o permanecer en Redis. Estos módulos comunitarios son funcionales, pero no ofrecen exactamente las mismas funcionalidades que sus equivalentes de Redis Stack.

En segundo lugar: quienes dependan de funciones empresariales de Redis, como la replicación geográfica activo-activo (Active-Active Geo-Replication), no encontrarán un equivalente en Valkey. Estas cargas de trabajo deben permanecer en Redis o migrarse a alternativas como Dragonfly o KeyDB.

En tercer lugar: las herramientas de observabilidad que analizan campos específicos del comando INFO de Redis pueden requerir ajustes ocasionales. Los principales proveedores de APM (Datadog, Grafana y New Relic) ya admiten Valkey de forma nativa, pero los paneles personalizados pueden presentar problemas.

Cuándo mantenerse en Redis y cuándo cambiar

La decisión es menos técnica que organizativa. Quienes utilizan en producción Redis Enterprise o los módulos de Redis Stack no disponen de una vía pragmática de migración, y Redis 8 bajo la licencia AGPLv3 resulta jurídicamente inofensivo para la mayoría de los casos de uso, siempre que el código no se revenda como servicio a terceros. La viralidad de la AGPL no se aplica en operaciones internas.

Por el contrario, quienes emplean Redis únicamente como caché clásico de clave-valor, utilizan servicios gestionados en AWS o Google Cloud y no requieren funciones empresariales, obtienen hoy una ventaja técnica clara con Valkey 9. Su licencia es más permisiva, su ritmo de incorporación de nuevas funciones es mayor y su integración con la nube, más profunda. Además, el riesgo de que un gran proveedor cloud retire su soporte es considerablemente menor en un proyecto respaldado por siete patrocinadores corporativos bajo la Fundación Linux que en el caso de un proveedor comercial único.

Para los equipos que comiencen nuevos proyectos en 2026, la cuestión ya está decidida: AWS ElastiCache y Google Memorystore desplegarán Valkey, no Redis, en todos los clústeres nuevos. Quien desee seguir usando Redis deberá firmar explícitamente un contrato comercial.

Conclusión

Tras 18 meses, el debate sobre las licencias ha llegado a su fin -no porque una de las partes haya perdido, sino porque ambas se han consolidado como opciones estables. Valkey 9 es la opción predeterminada técnicamente más activa y con licencia permisiva adoptada por los grandes proveedores cloud. Redis 8, bajo licencia AGPLv3, vuelve a ser software libre y ofrece mejoras de rendimiento, aunque no logra mantener el ritmo de lanzamientos de Valkey.

Para la mayoría de las cargas de trabajo en la nube en la región DACH (Alemania, Austria y Suiza), Valkey 9 es hoy la opción con menor riesgo. Quienes migren deberían comenzar con una caché no crítica, evaluar los módulos de la comunidad Valkey y aprovechar las opciones de actualización in situ que ofrezca su servicio gestionado. El «parche transparente» funciona en el 80 % de los casos; el 20 % restante requiere tiempo de planificación, pero no genera sorpresas.

Preguntas frecuentes

¿Es Valkey 9 completamente compatible con Redis?

Valkey 9 utiliza el protocolo de serialización de Redis (RESP) y es binariamente compatible con los clientes de Redis 7.2. El código de aplicaciones que emplea comandos estándar funciona sin modificaciones. No son compatibles los módulos de Redis Stack como RedisJSON, RediSearch y RedisBloom; para ellos existen equivalentes de la comunidad Valkey (Valkey-JSON, Valkey-Search, Valkey-Bloom), aunque aún no ofrecen una equivalencia funcional completa.

¿Qué ocurre con mis costes de licencia de Redis si paso a Valkey?

Valkey se distribuye bajo la licencia BSD 3-Clause y es totalmente gratuito, incluso para uso comercial y servicios gestionados. Los costes de servicios gestionados en AWS ElastiCache o Google Memorystore siguen aplicándose, pero sin tarifas adicionales por licencias de software. Quienes antes pagaban suscripciones a Redis Enterprise eliminan por completo esos gastos.

¿Puedo migrar en vivo entre Valkey 9 y Redis 8?

Sí, en ambas direcciones. AWS ElastiCache ofrece una ruta gestionada de actualización in situ desde Redis a Valkey con conmutación por error sin tiempo de inactividad. En entornos autoalojados, el proceso se realiza mediante replicación estándar: se configura una réplica Valkey contra un primario Redis, se espera a que finalice la replicación y luego se activa la conmutación por error. La compatibilidad RESP hace viables ambos sentidos, siempre que no se utilicen módulos propietarios de Redis.

¿Qué papel desempeñan Dragonfly y KeyDB en este debate?

Dragonfly y KeyDB son reimplementaciones compatibles con Redis que existen independientemente del debate entre Valkey y Redis, ofreciendo alternativas centradas en el rendimiento. Dragonfly apunta a un rendimiento extremo en nodos individuales mediante una arquitectura multihilo sin compartición (shared-nothing), mientras que KeyDB introduce multihilo dentro de la base de código de Redis. Ambas siguen siendo opciones relevantes para equipos con requisitos de latencia muy específicos; sin embargo, para casos de uso estándar de caché, Valkey 9 resulta la opción más pragmática debido a la ausencia de soporte en servicios gestionados por los grandes proveedores cloud (hyperscalers).

¿Es problemática la licencia AGPLv3 de Redis 8 para uso interno?

En la mayoría de los casos, no. La viralidad de la AGPLv3 entra en juego únicamente cuando se distribuye código modificado como servicio de red a terceros. Un uso interno típico de caché -donde la aplicación accede a Redis a través de la red sin modificar su código- es neutral respecto a la AGPLv3. No obstante, ante cualquier duda, se recomienda consultar al departamento jurídico, especialmente si se trata de productos SaaS que exponen funcionalidades basadas en Redis hacia el exterior.

¿Admite Google Memorystore ya Valkey 9 en producción?

Sí. Según el blog de Google Cloud, Memorystore para Valkey 9.0 alcanzó la disponibilidad general (GA) con su lanzamiento en octubre de 2025 y se ofrece activamente como vía de actualización desde instancias anteriores de Memorystore basadas en Redis. AWS ElastiCache y Oracle OCI Cache están implementando soporte de forma paralela. Para las regiones de Frankfurt esto significa que, al aprovisionar hoy un nuevo clúster, se obtiene Valkey 9 sin necesidad de configuración adicional.

¿Qué cambia en monitorización y alertas al migrar a Valkey?

Las métricas principales del comando INFO permanecen compatibles, por lo que los paneles estándar de Datadog, Grafana y New Relic funcionan sin modificaciones. Valkey añade campos adicionales para sus nuevas funcionalidades (estadísticas de subprocesos de E/S, estado de migración atómica de slots), que simplemente se ignoran en los paneles existentes. Quienes desarrollen sus propios analizadores o exportadores para Prometheus deberían probar una vez la salida de INFO contra Valkey 9 e incorporar, si es necesario, los nuevos campos en sus paneles.

Más del grupo editorial MBF Media

• Servicios gestionados: por qué las pymes externalizan la TI en lugar de desarrollarla internamente (MyBusinessFuture)
• Gobernanza de la IA en 2026: solo el 14 % ha definido quién asume la responsabilidad (Digital Chiefs)
• Autenticación de correo electrónico: cómo configurar correctamente SPF, DKIM y DMARC (SecurityToday)

Fuente de la imagen de portada: Pexels / Mikhail Nilov