Marzo de 2024. Estaba revisando una PR bastante aburrida cuando vi el anuncio de Redis Ltd.: a partir de la versión 7.4, Redis dejaba de ser BSD-3-Clause para pasar a un modelo dual con RSALv2 y SSPL. Cerré el anuncio, lo volví a abrir. Lo leí dos veces más.
Llevaba cuatro años con Redis corriendo en producción —caché de sesiones, rate limiting, pub/sub para notificaciones en tiempo real— y de repente tenía que decidir si ese stack seguía teniendo sentido.
Spoiler: terminé migrando a Valkey. Pero la decisión no fue tan obvia como parecía al principio.
Por Qué Redis Ltd. Cambió la Licencia (y Por Qué Duele)
La explicación oficial fue que los proveedores cloud —principalmente AWS, Google y Azure— estaban ganando dinero ofreciendo Redis como servicio gestionado sin contribuir significativamente al proyecto. Hay cierta lógica ahí. El problema es cómo lo resolvieron.
El SSPL (Server Side Public License) tiene una cláusula que básicamente dice: si ofreces el software como servicio, tienes que liberar también todo el código de tu infraestructura de servicio bajo SSPL. No solo el código que modificaste de Redis, sino todo lo que lo rodea. AWS claramente no iba a hacer eso. Ningún cloud provider iba a hacerlo.
La OSI (Open Source Initiative) rechazó el SSPL cuando MongoDB lo propuso en 2018. No es open source bajo ninguna definición reconocida. Redis Ltd. lo sabía. Lo eligieron igual.
Entonces, ¿qué pasó? En menos de dos semanas, la Linux Foundation anunció Valkey —un fork de Redis 7.2.4 bajo BSD-3-Clause— con el respaldo de AWS, Google Cloud, Oracle, Ericsson y otros. El 23 de marzo de 2024, Valkey tenía su propio repositorio. Para mayo, AWS ya había anunciado que ElastiCache migraría a Valkey. DigitalOcean y Aiven siguieron poco después.
Yo me quedé pensando: ¿esto es un rescate legítimo del open source o simplemente los cloud providers protegiéndose a sí mismos?
Honestamente, creo que es las dos cosas. Y eso no hace el fork menos válido.
Lo Que el Cambio de Licencia Significa en la Práctica Para Tu Proyecto
El análisis legal se complica rápido. Lo práctico es más simple.
Si usas Redis en tu propio servidor o en contenedores propios, la nueva licencia de Redis 7.4+ no te afecta directamente mientras no lo estés ofreciendo como servicio a terceros. Para la mayoría de startups y equipos de producto, eso significa que técnicamente podrías seguir usando Redis sin problema legal inmediato.
El asunto se complica en tres casos:
Primero, si dependes de un cloud provider que ahora ofrece Valkey en vez de Redis. Ya no tienes elección —estás en Valkey de facto. AWS empezó la migración automática de ElastiCache en 2025 y la mayoría de instancias ya están en Valkey 7.2.x o Valkey 8.x.
Segundo, si tu empresa tiene política de "solo OSI-approved licenses" (muchas empresas medianas y grandes tienen esto como requisito legal). Redis 7.4+ no pasa esa barrera. Valkey sí.
Tercero —y esto me tomó por sorpresa cuando lo investigué a fondo— algunas distribuciones de Linux ya eliminaron Redis de sus repos oficiales o lo marcaron como non-free. Debian, por ejemplo, movió Redis al área non-free. Si tu pipeline de CI/CD instala Redis desde los repos del sistema, ya estás afectado aunque no lo sepas.
Mi equipo de tres personas descubrió esto último de la peor manera posible: un pipeline de staging que instalaba Redis via apt dejó de funcionar un martes a las 11pm porque alguien hizo un apt upgrade en la imagen base. No fue prod, pero tampoco fue divertido.
Valkey 8.x: Lo Que Me Sorprendió Después de Migrar
Tenía expectativas bajas. Los forks apresurados suelen tener deuda técnica, documentación inconsistente y una comunidad que se va apagando después del momento inicial de entusiasmo. Me preparé para el peor caso.
No fue lo que encontré.
Valkey 7.2.x (el fork inicial) es esencialmente Redis 7.2.4 con el nombre cambiado y la licencia corregida. La compatibilidad es casi perfecta —el protocolo RESP, la API de comandos, los archivos de configuración. Cambiar redis-cli por valkey-cli es literalmente todo lo que necesité hacer en la mayoría de mis scripts de utilidad.
Pero Valkey 8.0, lanzado en septiembre de 2024, es donde se empezaron a ver las primeras divergencias reales:
# Verificar versión y algunas métricas nuevas en Valkey 8.x
valkey-cli INFO server | grep -E "valkey_version|io_threads_active"
# Output que vi en mi setup:
# valkey_version:8.0.2
# io_threads_active:4
# En Redis 7.4, el mismo campo sería redis_version
# y io_threads no está activo por defecto de la misma manera
El cambio más interesante en Valkey 8.0 fue la mejora en el I/O threading. Redis implementó multithreading para operaciones de red en Redis 6.0, pero el modelo seguía siendo single-threaded para la ejecución de comandos. Valkey 8.0 mejoró el pipeline del I/O threaded y, en mis pruebas con cargas de lectura intensiva (básicamente GET/SET con payloads de ~1KB), vi entre un 15% y un 22% de mejora en throughput contra Redis 7.2.
No soy 100% seguro de que ese número se sostenga en todas las cargas de trabajo —mi setup específico favorece lecturas— pero es más de lo que esperaba de un proyecto con menos de un año de vida independiente.
Lo que sí me decepcionó: la documentación en 2024 era bastante escasa. Muchas páginas eran copias directas de la doc de Redis con el nombre cambiado, sin actualizar ejemplos ni aclarar las diferencias nuevas. Para principios de 2025 había mejorado bastante. En 2026 ya está en un estado decente, aunque todavía hay secciones donde claramente falta trabajo.
Dos Semanas Migrando en Producción: Lo que Realmente Pasó
El plan inicial era simple: alias de red, mismo puerto, cambiar el binario, listo. Y en su mayor parte funcionó exactamente así.
La arquitectura que migré: tres instancias Redis en un cluster de replicación primario/réplica, con Sentinel para failover automático. Aproximadamente 8GB de datos en memoria, mezcla de strings, hashes y sorted sets. Unas 12,000 operaciones por segundo en hora pico.
# El cambio más invasivo en código fue esto — casi ninguno
import redis # El cliente de Python siguió funcionando sin cambios
r = redis.Redis(
host='valkey-primary.internal', # Solo cambié el hostname
port=6379,
decode_responses=True
)
# Todo lo demás igual. ZADD, HGET, SETEX, Pub/Sub — sin cambios.
r.zadd('leaderboard', {'user:1042': 9850.5})
score = r.zscore('leaderboard', 'user:1042')
El cliente de Python redis-py funciona con Valkey sin modificaciones. Lo mismo con los clientes de Node.js, Go y Java que usamos. Valkey es intencionalmente compatible con el protocolo de Redis —eso era un requisito del fork desde el día uno.
Donde sí tuve problemas: Valkey Sentinel tiene algunas diferencias de comportamiento en edge cases de failover. Específicamente, durante una prueba de failover intencional (déjame ser honesto: fue un kill -9 en el primario un viernes a las 4pm porque pensé que teníamos tiempo suficiente para resolver problemas antes del fin de semana), el tiempo de elección del nuevo primario fue más lento de lo esperado —unos 35 segundos vs los ~8 segundos que veía con Redis Sentinel.
Después de investigarlo, resultó ser un parámetro de configuración que no había migrado correctamente: sentinel down-after-milliseconds. El valor por defecto en mi instalación nueva de Valkey era diferente al que tenía en Redis. Cinco minutos de config fix, problema resuelto. Pero me costó esa tarde de viernes.
Una advertencia que no puedes ignorar: los módulos. Si usas RedisSearch, RedisJSON, RedisTimeSeries o cualquier módulo de Redis Stack, esos son propietarios de Redis Ltd. y no son compatibles con Valkey. Existen proyectos comunitarios alternativos, pero la paridad de features no es completa. Si dependes fuertemente de estos módulos, la migración es considerablemente más complicada.
En mi caso no usaba ninguno. Suerte de principiante, supongo.
Mi Veredicto: Cuándo Elegir Cada Uno (Sin Rodeos)
Después de dos semanas de migración y seis meses más usando Valkey en producción, esto es lo que pienso —sin pretender que es una decisión neutral:
Usa Valkey si:
Tu infraestructura está en un cloud provider que ya migró (AWS, GCP, DigitalOcean, Aiven) — no tienes opción y no es un problema. Si estás empezando un proyecto nuevo hoy, Valkey es la decisión obvia: licencia limpia, respaldo institucional fuerte, y la distancia técnica con Redis en casos de uso comunes es mínima o favorable.
El ecosistema de Valkey en 2026 ya tiene masa crítica. La mayoría de herramientas de observabilidad (Datadog, Prometheus exporters, etc.) soportan Valkey. Los frameworks que tenían integraciones con Redis las tienen con Valkey —algunos por compatibilidad directa, otros con soporte explícito.
Sigue con Redis si:
Dependes de Redis Stack y los módulos propietarios (RedisSearch en particular) son parte central de tu arquitectura. Migrar eso hoy tiene un costo real. Además, si tienes un contrato de soporte con Redis Ltd., tiene sentido mantenerse en su ecosistema mientras dure.
También hay un argumento de inercía legítimo: si Redis 7.2.x o anterior corre perfectamente en tu infraestructura propia y no tienes razones de licencia para cambiar, la presión de migrar no es urgente. Aunque el riesgo real permanece — Redis Ltd. ya demostró que puede cambiar las reglas cuando le convenga. El fork de Valkey existió exactamente porque ese riesgo se materializó.
Personalmente, no volvería a Redis para un proyecto nuevo. La incertidumbre de licencia existe, el ecosistema de Valkey ya es lo suficientemente maduro, y los números de rendimiento en Valkey 8.x me gustaron más de lo que esperaba. No es una decisión emocional contra Redis Ltd. —es pragmatismo.
La conclusión es sencilla: Valkey ganó el fork porque los cloud providers lo necesitaban, y eso resultó ser suficiente para llevarse el ecosistema también.
Top comments (0)