Valkey cumple 1 año: cómo el fork comunitario superó a Redis

• Redis Inc sacudió la confianza de la comunidad con su decisión de cerrar el código fuente (cambio a SSPL), pero la comunidad de desarrolladores se unió en torno al fork Valkey, impulsando una innovación activa y contribuciones continuas
• Redis 8.0 volvió a ser open source, y el fundador Antirez regresó para participar en nuevas funciones y optimizaciones, por lo que ambos bandos están avanzando con rapidez
• Según los benchmarks más recientes, Valkey 8.1.1 en un entorno de 8 vCPU ofrece un rendimiento de SET 37% superior al de Redis 8.0, y también registró una latencia p99 más baja (GET también aventaja en 16%)
• Con técnicas de ajuste en producción como hilos de IO y fijación de núcleos, Valkey logró aumentar más de 3 veces el throughput en entornos multihilo y minimizar la latencia
• También se comparten benchmarks más cercanos a entornos reales y recomendaciones de tuning, junto con advertencias para interpretar los resultados y aplicarlos en operación real

---

El cierre del código de Redis y la aparición de Valkey

• Hace un año, Redis Inc (antes Garantia Data) deterioró su relación de confianza con la comunidad al cambiar su licencia open source (adopción de SSPL)
• Como respuesta surgió el fork abierto Valkey, que se ha convertido en un activo tecnológico ampliamente usado en sistemas distribuidos, caché y procesamiento de datos en tiempo real
• Posteriormente, Redis también intentó recuperar la confianza con el regreso de Antirez (fundador), mejoras de rendimiento y funciones, y el retorno de Redis 8.0 al modelo open source

Valkey 8.1 vs Redis 8.0: comparación de rendimiento

• Benchmark de SET en las mismas condiciones: instancia AWS c8g.2xl de 8 vCPU, ítems de 1 KB, keyspace de 3 M y 500 conexiones
  • Valkey 8.1.1: 999.8K RPS (p99 0.8ms)
  • Redis 8.0: 729.4K RPS (p99 0.99ms)
  • Valkey es 37% más rápido en SET y 16% en GET; además, el p99 de SET es 30% mejor y el de GET 60% mejor
• Al usar 6 hilos de IO, Valkey pasó de 239K → 678K RPS (2.8x↑), y p99 de 1.68ms → 0.93ms (44%↓)
• Redis también mejoró con hilos de IO: 235K → 563K RPS, p99 de 1.35ms → 0.84ms (40%↓)

Efecto del ajuste de multihilo y núcleos

• Los hilos de IO muestran un efecto importante a partir de 3 hilos, y Valkey amplía su ventaja sobre Redis a partir de 4 hilos
• Si se limitan los núcleos de IRQ (interrupciones) a 2 y luego Redis/Valkey se fijan a los 6 núcleos restantes (pinning), se obtiene una mejora adicional de rendimiento
  • Valkey: 832K → 999.8K RPS (pinning de núcleo/IRQ, uso de CPU al 80%)
  • Separar los núcleos de IRQ y de la aplicación mejora la eficiencia de caché y minimiza la tail latency
  • También se incluye un ejemplo real con Docker usando cpuset-cpus, --io-threads, etc.

Reproducción del benchmark y consejos prácticos

• Uso de instancias AWS Graviton4 (c8g.2xlarge) de última generación y cluster placement group
• Máximo rendimiento mediante core pinning / separación de IRQ / ajuste del número de conexiones (en el rango de 400 a 500)
• También es necesario ajustar el keyspace y el tamaño de los ítems; valores y keyspaces pequeños aumentan la tasa de aciertos de caché L3
• Se recomienda usar activamente herramientas de benchmark multihilo como valkey-benchmark o rpc-perf (herramienta en Rust más cercana al uso real)

  docker run --network="host" --rm --cpuset-cpus="2-7" \  
  valkey/valkey:8.0.1 valkey-benchmark \  
  -h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
  -r 3000000 --threads 6 -d 1024  
  

Límites y consideraciones al medir rendimiento

• Los resultados de benchmark pueden diferir del entorno real de operación

  • Las cargas reales incluyen factores complejos como mezcla de SET:GET, variación de carga, objetivos de TPS y latencia de red
  • Cuando el número de conexiones aumenta bruscamente, también se observa mayor latencia de cola, menor throughput y aumento de la tail latency
  • Los resultados pueden variar considerablemente según la herramienta/opciones de benchmark y la topología de red

Principales avances y desarrollo de la comunidad

El proyecto Valkey ha mostrado un desarrollo muy activo en diversos frentes durante el último año

• Con la colaboración de muchos desarrolladores y empresas en GitHub y otros espacios, se añadieron funciones, se corrigieron bugs y se mejoró la seguridad
• También se reforzaron la documentación y el soporte a usuarios para reducir la barrera de entrada de nuevos usuarios
• En la gestión del proyecto se enfatizan la toma de decisiones transparente y la votación de la comunidad

Valor técnico y en la industria

Valkey tiene fortalezas como las siguientes

• Al poder ser usado por cualquiera sin restricciones de licencia, es una opción atractiva para proveedores de servicios cloud y empresas de servicios web a gran escala
• Tiene alta compatibilidad con Redis, por lo que la migración también es sencilla
• Al estar impulsado por la comunidad, puede reflejar diversos requisitos y mantener actualizaciones continuas con rapidez

Conclusión e implicaciones

• Valkey ha mostrado, a solo un año de nacer como fork de Redis, resultados que superan a Redis en tecnología, rendimiento y comunidad
• Las claves están en herramientas y técnicas de tuning reales como hilos de IO, separación de núcleo/IRQ y ajuste de conexiones
• El rendimiento no llega automáticamente; es indispensable una optimización continua ajustada al sistema, la carga de trabajo y la infraestructura
• En entornos de servicio reales, se necesita un enfoque práctico que no dependa solo de las cifras de benchmark, sino que pruebe directamente distintos escenarios

[ethanhur]

Aunque Redis tomó muchas malas decisiones, da pena que parezca que el oso hace el trabajo y el domador se lleva el dinero.

[kgcrom]

Publicado en el grupo de Facebook "Redis User Group"
Es un material que resume qué mejoras se realizaron en Valkey 8.
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

Si lo ven junto con el contenido de arriba, probablemente ayude a entenderlo.

[ndrgrd]

En realidad, no es que Valkey haya hecho gran cosa... más bien, del otro lado se hundieron solos...

[GN⁺]

Opiniones en Hacker News

• Me alegra que Valkey haya logrado avances geniales en I/O threading, y que también haya empezado a introducir algunos de los cambios más interesantes últimamente. Muchas gracias a quienes contribuyen a Valkey. Pero creo que este artículo tiende un poco a inducir a error. En Redis, la arquitectura shared nothing siempre fue una filosofía muy importante, y yo mismo fui quien introdujo el I/O threading en 2020. Sin romper la intención de shared nothing, y considerando que las syscalls write(2)/read(2) pueden ser bastante lentas al volver del event loop, se introdujo una estructura donde justo en ese momento solo el I/O se procesa en paralelo con N threads en estado de zero contention, y luego se vuelve de inmediato al modo single-thread. Agradezco que el equipo de Valkey haya seguido desarrollando este sistema. Este sistema ya venía funcionando desde antes, y me incomoda que la prensa exagere datos que en la práctica no han cambiado. En realidad, estas funciones interesan más a usuarios empresariales o proveedores cloud como Amazon o Google que a la mayoría de los usuarios comunes de Redis. A menos que no haya otra opción que manejar una carga enorme o muchísimos usuarios al mismo tiempo, la realidad es que en la mayoría de los casos Redis tiene bajo uso de CPU, así que no hace falta activarlas. Últimamente, al desarrollar el tipo de dato vector set en Redis, se está tomando el threading como valor predeterminado, y también se está permitiendo que la escritura de vector sets mediante VADD se haga con threads. Estructuras de datos como HNSW introducen por primera vez en la historia de Redis tiempos constantes enormes, así que el espacio de diseño cambia por completo. Antes también ya se había implementado soporte de threads para módulos. La decisión de usar threads o no depende del contexto.
  • Un punto de vista matizado no genera clics.
  • Siento que este tipo de posts críticos llega a la portada de HN cada mes, y siempre me dieron ganas de apoyar a antirez. Estoy de acuerdo con el punto técnico, pero creo que estas críticas a menudo tienen menos que ver con el contenido concreto y más con el clásico tall poppy syndrome, esa tendencia a querer bajar a quien tuvo mucho éxito. Como no puedes controlar la reacción de los demás, quizá sea más sano tomar estos posts críticos como un reconocimiento indirecto de la magnitud de tus logros. También agradezco haber conectado contigo en LinkedIn. Ver tall poppy syndrome
• Recuerdo que antirez anunció que Redis volvería a ser open source. Post relacionado Antes Node.js casi se vino abajo por el fork de Io.js, pero la comunidad logró recuperarlo. Me pregunto si Redis podrá tener una recuperación similar. Antes usaba Redis con frecuencia, pero en los últimos años no he seguido muy de cerca cómo va la comunidad.
  • La última vez que revisé, Redis todavía exigía un CLA. Eso significa que conserva el derecho exclusivo de volver a cerrar el código cuando quiera. Si los contribuidores tienen que aceptar esa cláusula, no hay motivo para confiar en que no vayan a hacer lo mismo otra vez.
  • Redis se distribuye bajo AGPL y Valkey bajo licencia BSD, que era la licencia anterior de Redis. Ambas son licencias open source oficiales, pero BSD es mucho más permisiva.
  • Si soy sincero, al 99% de los usuarios les da igual quién sea el dueño mientras el key-value store gratuito funcione bien. Desde el punto de vista del negocio, Redis está en una posición peculiar: ofrece muchísimas funciones, pero en producción la mayoría solo usa el 5%. No les interesan funciones complejas como Sentinel o Streams. Cuando intentan monetizarlo, el usuario tiene varias opciones: "simplemente dejar de usarlo", "migrar a un competidor", "crear por su cuenta solo las funciones que realmente necesita", o "hacer fork de la última versión open source y mantenerla internamente para ahorrar costos". Comparado con PostgreSQL, una versión simple de Redis (hashmap + interfaz de red) es relativamente fácil de construir por cuenta propia, así que para muchos negocios hacer fork o crear algo propio termina siendo la mejor opción.
  • Yo también siento que ya es demasiado tarde. Después del cambio brusco de política de Redis, para mí Redis ahora es algo en lo que no se puede confiar, y de aquí en adelante Valkey será la opción por defecto. Si te engañan una vez, no vuelves a confiar dos veces.
  • Después de todo lo que hizo Redis, ¿cómo se supone que uno vuelva a confiar?
• Creo que Valkey debería estar en el package manager por defecto de las distribuciones. Por ejemplo, cuando intento instalarlo en un GitHub Action runner, es molesto tener que agregar la key y actualizar la distribución cada vez.
  • ¿En qué distribución no está? Según los datos de repology, ya está en nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL, etc. Eso sí, en Debian es a partir de la 13 o de la 12+backports.
  • Como referencia, en Arch Linux Valkey ya reemplaza a Redis.
  • Si en CI lo primero que haces al recibir una imagen de contenedor es instalar varias cosas, mejor crea tu propia imagen.
• Me da mucho gusto que este cambio haya ocurrido y que Valkey siga avanzando bien. Ojalá Redis desaparezca pronto.
  • Tono sarcástico sobre que el open source termina siendo para monopolios. Los hyperscalers como AWS ganan cientos de millones de dólares con Redis, pero los desarrolladores y contribuidores reales no reciben ese beneficio. Por eso, las startups de bases de datos deberían arrancar desde el inicio con una licencia fair source, con cláusulas anti-hyperscaler, de forma que cualquiera pueda usar libremente el código, pero que AWS o Google tengan que pagar si quieren ofrecerlo como Managed Service. Redis y Elasticsearch, que empezaron con licencias ultra permisivas, ya tienen un destino difícil de revertir.
• Últimamente varios proyectos de dotnet se están volviendo comerciales. Para los desarrolladores, estos cambios se sienten como un rug pull, una traición repentina a la confianza. Ese ambiente podría también afectar la adopción de otras librerías open source de dotnet.
  • En .NET esta tendencia hacia la comercialización no es algo reciente; siempre ha tenido esa inclinación en la que freeware/open-core y negocio van de la mano.
• Escucho de Valkey desde el año pasado, y me alegra ver que sigue yéndole bien.
• Me pregunto si Valkey ofrece sus propias client libraries. Actualmente, en GCP uso tanto MemoryStore como entornos autogestionados, con Redis y Redis Cluster. La librería oficial de C me decepcionó cuando quise usar Redis Cluster+TLS, así que terminé teniendo que usar un cliente no oficial, hiredis-cluster (https://github.com/Nordix/hiredis-cluster). Tampoco estoy muy satisfecho con Memorystore de GCP. Estoy considerando migrar a Scylla.
  • Hay un fork oficial llamado libvalkey que combina hiredis y hiredis-cluster, mantenido por quienes ya mantenían esos proyectos. Ver libvalkey
• Ahora que Redis cambió su política, me pregunto si Valkey y Redis podrían hablar y reunificarse.
  • El punto es que no volvió a la licencia original, sino que se pasó a AGPL, así que no es un verdadero giro en U.
• Comparten un muy buen texto que explica el FUD esperado alrededor de GPL. Post relacionado
  • Me parece que afirmar en el post que las licencias copyleft son más libres es un razonamiento algo fácil. A medida que aumentan las obligaciones, disminuye la libertad en cierto sentido, así que la discusión sobre qué estilo es más “libre” me parece más profunda.
• Uso Redis en decenas de aplicaciones. Como AWS ofrecía Valkey con descuento, lo probé hace dos meses y no noté ninguna diferencia de rendimiento. Pero de repente Valkey dejó de responder; AWS seguía detectándolo como en ejecución, pero la conexión se cortó por completo. No se recuperó en más de 12 horas, y volvió a pasar. AWS investigó durante dos semanas y no logró encontrar la causa. Después de eso, se me hace difícil usar Valkey en entornos mission-critical. Luego lo cambié por Redis con la misma carga de trabajo y no hubo problemas.
  • Quizá sea un problema de AWS. Nosotros vivimos algo parecido con un clúster de RDS Postgres en producción. La red dejó de responder y, aunque teníamos soporte enterprise de AWS, al final terminamos restaurando un backup por nuestra cuenta para crear un clúster nuevo; tomó 4 horas. Desde entonces evitamos los servicios encapsulados de AWS y migramos a EC2 normal con replicación, snapshots y réplica a S3.
  • También podría ser un problema operativo de AWS. Solo he corrido Redis directamente, pero puede que no sea un problema de Valkey en sí.
  • Me pregunto por qué no levantas una instancia de Valkey directamente.
  • ¿Qué tipo de instancia usaste? Lo pregunto como referencia.