Valkey como sustituto de Redis: migración real con Valkey 8.1

Actualizado: 2026-05-03

Valkey 8.1 salió el 31 de marzo y es la versión que me ha hecho tomar en serio la migración. Hasta ahora estábamos probándolo en staging desde la bifurcación de marzo de 2024, cuando Redis cambió su licencia y la Linux Foundation amparó a Valkey como continuación libre. Valkey 8.0 en septiembre ya era sólido, pero las mejoras de multi-threading en 8.1 cerraron el último hueco que me frenaba. Hace dos semanas migramos el primer cluster de producción. Este post cuenta esa migración sin promoción ni crítica gratuita.

Para el contexto histórico del cambio de licencia de Redis, el post sobre Valkey como fork de Redis cubre los antecedentes del cambio que precipitó este escenario.

Puntos clave

• Valkey 8.1 es compatible en protocolo y comandos con Redis 7.x; la mayoría de clientes existentes funcionan sin cambios.
• La migración más sencilla es dump/restore; la sin downtime requiere replicación asimétrica y es viable pero tiene consideraciones.
• El rendimiento en carga real es comparable o ligeramente superior al de Redis 7.2 en I/O-bound; las mejoras de multi-threading en 8.1 se notan en CPU-bound.
• Los puntos de ajuste que encontramos: configuración de módulos, nombres de métricas en exporters, y clients que hardcodeaban strings de versión.
• Valkey mantiene Redis Cluster y Sentinel; no hay cambio en el modelo de alta disponibilidad.

Por qué Valkey 8.1 cambia la ecuación

La bifurcación de marzo de 2024 era inevitable una vez Redis cambió de BSD a SSPL. El ecosistema open source necesitaba una alternativa que pudiera recibir contribuciones sin restricciones de licencia. La Linux Foundation respaldando a Valkey le dio credibilidad institucional, y el hecho de que AWS, Google Cloud y otros proveedores cloud empezaran a ofrecer Valkey como opción de caché gestionado aceleró la adopción.

Lo que distingue 8.1 de las versiones anteriores es el I/O threading mejorado. Redis siempre fue single-threaded para comandos, con I/O multithreaded desde Redis 6. Valkey 8.1 refina ese modelo: el bucket mutex granular reduce la contención en workloads con muchas keys pequeñas, que es el patrón de caché web típico. En nuestras pruebas de carga, vimos una reducción de latencia p99 de alrededor del 15% respecto a Redis 7.2 en el mismo hardware, con el mismo workload de caché de sesiones.

Compatibilidad: lo que funciona sin tocar nada

Valkey implementa el mismo protocolo RESP2 y RESP3 que Redis. Los comandos son idénticos para el conjunto core: strings, hashes, sets, sorted sets, lists, streams, HyperLogLog, pub/sub, scripting con Lua, transacciones MULTI/EXEC. La configuración en valkey.conf sigue la misma estructura que redis.conf, con las mismas directivas.

Los clientes que probamos sin modificación:

• redis-py (Python): funciona completamente, incluyendo cluster mode y pipeline.
• Jedis y Lettuce (Java): funciona, incluyendo pooling y sentinel.
• ioredis (Node.js): funciona, incluyendo cluster.
• go-redis (Go): funciona.

No hubo que cambiar una sola línea de código de aplicación. El switch fue a nivel de infraestructura: cambiar la imagen del contenedor de redis:7.2 a valkey/valkey:8.1 en el docker-compose.

Los puntos donde tuvimos que ajustar

Aunque la compatibilidad es alta, hubo tres áreas donde encontramos fricción:

Módulos. Usábamos RedisJSON y RediSearch. Valkey no carga módulos de Redis directamente, y los equivalentes de Valkey (json y search como módulos propios) aún tienen diferencias en algunos comandos avanzados. Decidimos no migrar los datos que dependían de módulos y mantener un Redis separado para ese uso, que es un porcentaje pequeño del workload total.

Métricas del exporter. El redis_exporter de Oliver006 funciona con Valkey, pero algunos nombres de métricas han cambiado en 8.1. Las alertas de Prometheus que referenciaban métricas específicas de Redis tuvieron que actualizarse. No fue trabajo mayor, pero requirió pasar por cada alerta y verificar que el nombre de métrica correspondía. El exporter actualizado ya incluye compatibilidad con los nuevos nombres.

Clients con string matching de versión. Teníamos un cliente interno que parseaba la salida de INFO server para determinar si el servidor era «Redis» y qué versión. Con Valkey, la salida de INFO server devuelve redis_version: 7.2.x para compatibilidad, pero también añade valkey_version: 8.1.x. El código que buscaba redis_version seguía funcionando, pero el que buscaba el string literal «Redis» en la salida de INFO server fallaba. Fue un bug fácil de arreglar pero fácil de no anticipar.

La migración: dump/restore vs. replicación asimétrica

Para el cluster que migramos, optamos por el approach de dump/restore con ventana de mantenimiento de 15 minutos. El proceso fue:

1. SAVE en Redis para generar el RDB más reciente.
2. Copiar el RDB al nuevo servidor Valkey.
3. Arrancar Valkey con el RDB cargado.
4. Verificar la consistencia con una muestra de keys.
5. Cambiar los endpoints en la configuración de la aplicación.
6. Reiniciar la aplicación.

Para workloads que no toleran downtime, la vía alternativa es la replicación asimétrica: configurar Valkey como réplica de Redis, dejar que sincronice, luego promoverla a primaria y reapuntar los clientes. Esta vía funciona porque Valkey entiende el protocolo de replicación de Redis, pero hay que verificar la compatibilidad de versiones (Valkey 8.1 puede replicar desde Redis 7.x pero no de versiones más antiguas sin saltos de versión intermedios).

Rendimiento en producción: las dos semanas siguientes

Después de dos semanas en producción, los números son consistentes con las pruebas de staging:

• Latencia p50 prácticamente idéntica a Redis 7.2 en nuestro workload de caché.
• Latencia p99 alrededor de 12-15% mejor en horas pico, cuando la carga de I/O es alta.
• Uso de CPU ligeramente más eficiente en los workers de I/O.
• Sin ningún incidente relacionado con la migración.

El consumo de memoria es esencialmente el mismo; Valkey no tiene mejoras significativas en ese área en 8.1 (hay trabajo en progreso para estructuras de datos más eficientes en versiones futuras).

Mi lectura

Valkey 8.1 es producción-ready para el caso de uso de caché. La compatibilidad de protocolo y comandos es suficientemente alta para que la mayoría de equipos puedan migrar sin tocar el código de aplicación. Las áreas de fricción son conocidas y manejables: módulos de terceros, exporters de métricas, y código que hace assumptions sobre el string de versión.

La pregunta no es ya «¿es Valkey lo suficientemente maduro?» sino «¿cuál es el incentivo para migrar?». Si usas Redis bajo licencia open source (Redis Stack o los módulos bajo SSPL) y eso no te genera preocupación legal, el incentivo es menor. Si usas Redis OSS 6.x o 7.x y estás evaluando una renovación de infraestructura, Valkey 8.1 es la alternativa más directa que existe hoy.