Marzo de 2024. Estaba revisando una PR bastante aburrida cuando vi el anuncio de Redis Ltd.: a partir de la versi\u00f3n 7.4, Redis dejaba de ser BSD-3-Clause para pasar a un modelo dual con RSALv2 y SSPL. Cerr\u00e9 el anuncio, lo volv\u00ed a abrir. Lo le\u00ed dos veces m\u00e1s.<\/p>\n
Llevaba cuatro a\u00f1os con Redis corriendo en producci\u00f3n<\/a> \u2014cach\u00e9 de sesiones, rate limiting, pub\/sub para notificaciones en tiempo real\u2014 y de repente ten\u00eda que decidir si ese stack segu\u00eda teniendo sentido.<\/p>\n Spoiler: termin\u00e9 migrando a Valkey. Pero la decisi\u00f3n no fue tan obvia como parec\u00eda al principio.<\/p>\n La explicaci\u00f3n oficial fue que los proveedores cloud \u2014principalmente AWS, Google y Azure\u2014 estaban ganando dinero ofreciendo Redis como servicio gestionado sin contribuir significativamente al proyecto. Hay cierta l\u00f3gica ah\u00ed. El problema es c\u00f3mo lo resolvieron.<\/p>\n El SSPL (Server Side Public License) tiene una cl\u00e1usula que b\u00e1sicamente dice: si ofreces el software como servicio, tienes que liberar tambi\u00e9n todo el c\u00f3digo de tu infraestructura de servicio bajo SSPL. No solo el c\u00f3digo que modificaste de Redis, sino todo lo que<\/a> lo rodea. AWS claramente no iba a hacer eso. Ning\u00fan cloud provider iba a hacerlo.<\/p>\n La OSI (Open Source Initiative) rechaz\u00f3 el SSPL cuando MongoDB lo propuso en 2018. No es open source bajo ninguna definici\u00f3n reconocida. Redis Ltd. lo sab\u00eda. Lo eligieron igual.<\/p>\n Entonces, \u00bfqu\u00e9 pas\u00f3? En menos de dos semanas<\/a>, la Linux Foundation anunci\u00f3 Valkey \u2014un fork de Redis 7.2.4 bajo BSD-3-Clause\u2014 con el respaldo de AWS, Google Cloud, Oracle, Ericsson y otros. El 23 de marzo de 2024, Valkey ten\u00eda su propio repositorio. Para mayo, AWS ya hab\u00eda anunciado que ElastiCache migrar\u00eda a Valkey. DigitalOcean y Aiven siguieron poco despu\u00e9s.<\/p>\n Yo me qued\u00e9 pensando: \u00bfesto es<\/a> un rescate leg\u00edtimo del open source o simplemente los cloud providers protegi\u00e9ndose a s\u00ed mismos?<\/p>\n Honestamente, creo que es las dos cosas. Y eso no hace el fork menos v\u00e1lido.<\/p>\n El an\u00e1lisis legal se complica r\u00e1pido. Lo pr\u00e1ctico es m\u00e1s simple.<\/p>\n Si usas Redis en tu propio servidor o en contenedores propios, la nueva licencia de Redis 7.4+ no te afecta directamente<\/strong> mientras no lo est\u00e9s ofreciendo como servicio a terceros. Para la mayor\u00eda de startups y equipos de<\/a> producto, eso significa que t\u00e9cnicamente podr\u00edas seguir usando Redis sin problema legal inmediato.<\/p>\n El asunto se complica en tres casos:<\/p>\n Primero, si dependes de un cloud provider que ahora ofrece Valkey en vez de Redis. Ya no tienes elecci\u00f3n \u2014est\u00e1s en Valkey de facto. AWS empez\u00f3 la migraci\u00f3n autom\u00e1tica de ElastiCache en 2025 y la mayor\u00eda de instancias ya est\u00e1n en Valkey 7.2.x o Valkey 8.x.<\/p>\n Segundo, si tu empresa tiene pol\u00edtica de “solo OSI-approved licenses” (muchas empresas medianas y grandes tienen esto como requisito legal). Redis 7.4+ no pasa esa barrera. Valkey s\u00ed.<\/p>\n Tercero \u2014y esto<\/a> me tom\u00f3 por sorpresa cuando lo investigu\u00e9 a fondo\u2014 algunas distribuciones de Linux ya eliminaron Redis de sus repos oficiales o lo marcaron como non-free. Debian, por ejemplo, movi\u00f3 Redis al \u00e1rea Mi equipo de tres personas descubri\u00f3 esto \u00faltimo de la peor manera posible: un pipeline de staging que instalaba Redis via apt dej\u00f3 de funcionar un martes a las<\/a> 11pm porque alguien hizo un apt upgrade en la imagen base. No fue prod, pero tampoco fue divertido.<\/p>\n Ten\u00eda expectativas bajas. Los forks apresurados suelen tener deuda t\u00e9cnica, documentaci\u00f3n inconsistente y una comunidad que se va apagando despu\u00e9s del momento inicial de entusiasmo. Me prepar\u00e9 para el peor caso.<\/p>\n No fue lo que<\/a> encontr\u00e9.<\/p>\n 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 \u2014el protocolo RESP, la API de comandos, los archivos de configuraci\u00f3n. Cambiar Pero Valkey 8.0, lanzado en septiembre de 2024, es donde se empezaron a ver las primeras divergencias reales:<\/p>\n El cambio m\u00e1s interesante en Valkey 8.0 fue la mejora en el<\/a> I\/O threading. Redis implement\u00f3 multithreading para operaciones de red en Redis 6.0, pero el modelo segu\u00eda siendo single-threaded para la ejecuci\u00f3n de comandos. Valkey 8.0 mejor\u00f3 el pipeline del I\/O threaded y, en mis pruebas con cargas de lectura intensiva (b\u00e1sicamente GET\/SET con payloads de ~1KB), vi entre un 15% y un 22% de mejora en throughput contra Redis 7.2.<\/p>\n No soy 100% seguro de que ese n\u00famero se sostenga en todas las cargas de trabajo \u2014mi setup espec\u00edfico favorece lecturas\u2014 pero es m\u00e1s de lo que<\/a> esperaba de un proyecto con menos de un a\u00f1o de vida independiente.<\/p>\n Lo que s\u00ed me decepcion\u00f3: la documentaci\u00f3n en 2024 era bastante escasa. Muchas p\u00e1ginas 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\u00eda mejorado bastante. En 2026<\/a> ya est\u00e1 en un estado decente, aunque todav\u00eda hay secciones donde claramente falta trabajo.<\/p>\n El plan inicial era simple: alias de red, mismo puerto, cambiar el binario, listo. Y en su mayor parte funcion\u00f3 exactamente as\u00ed.<\/p>\n La arquitectura que migr\u00e9: tres instancias Redis en un cluster de replicaci\u00f3n primario\/r\u00e9plica, con Sentinel para failover autom\u00e1tico. Aproximadamente 8GB de datos<\/a> en memoria, mezcla de strings, hashes y sorted sets. Unas 12,000 operaciones por segundo en hora pico.<\/p>\n El cliente de Python Donde s\u00ed tuve problemas: Valkey Sentinel tiene algunas diferencias de comportamiento en edge cases de failover. Espec\u00edficamente, durante una prueba de failover intencional (d\u00e9jame ser honesto: fue un Despu\u00e9s de investigarlo, result\u00f3 ser un par\u00e1metro de configuraci\u00f3n que no hab\u00eda migrado correctamente: Una advertencia que no puedes ignorar: los m\u00f3dulos. Si usas RedisSearch, RedisJSON, RedisTimeSeries o cualquier m\u00f3dulo de Redis Stack, esos son propietarios de Redis Ltd. y no son compatibles con Valkey<\/strong>. Existen proyectos comunitarios alternativos, pero la paridad de features no es completa. Si dependes fuertemente de estos m\u00f3dulos, la migraci\u00f3n es considerablemente m\u00e1s complicada.<\/p>\n En mi caso no usaba ninguno. Suerte de principiante, supongo.<\/p>\n Despu\u00e9s de dos semanas<\/a> de migraci\u00f3n y seis meses m\u00e1s usando Valkey en producci\u00f3n<\/a>, es lo<\/a> que”>esto es lo<\/a> que<\/a> pienso \u2014sin pretender que es una decisi\u00f3n neutral:<\/p>\n Usa Valkey si:<\/strong><\/p>\n Tu infraestructura est\u00e1 en un cloud provider que ya migr\u00f3 (AWS, GCP, DigitalOcean, Aiven) \u2014 no tienes opci\u00f3n y no es un problema. Si est\u00e1s empezando un proyecto nuevo hoy, Valkey es la decisi\u00f3n obvia: licencia limpia, respaldo institucional fuerte, y la distancia t\u00e9cnica con Redis en casos de uso comunes es m\u00ednima o favorable.<\/p>\n El ecosistema de Valkey en 2026<\/a> ya tiene masa cr\u00edtica. La mayor\u00eda de herramientas de observabilidad (Datadog, Prometheus exporters, etc.) soportan Valkey. Los frameworks que ten\u00edan integraciones con Redis las tienen con Valkey \u2014algunos por compatibilidad directa, otros con soporte expl\u00edcito.<\/p>\n Sigue con Redis si:<\/strong><\/p>\n Dependes de Redis Stack y los m\u00f3dulos propietarios (RedisSearch en particular) son parte central de tu arquitectura. Migrar eso hoy tiene un costo real. Adem\u00e1s, si tienes un contrato de soporte con Redis Ltd., tiene sentido<\/a> mantenerse en su ecosistema mientras dure.<\/p>\n Tambi\u00e9n hay un argumento de inerc\u00eda leg\u00edtimo: si Redis 7.2.x o anterior corre perfectamente en tu infraestructura propia y no tienes razones de licencia para cambiar, la presi\u00f3n de migrar<\/a> no es urgente. Aunque el riesgo real permanece \u2014 Redis Ltd. ya demostr\u00f3 que puede cambiar las reglas cuando le convenga. El fork de Valkey existi\u00f3 exactamente porque ese riesgo se materializ\u00f3.<\/p>\nPor Qu\u00e9 Redis Ltd. Cambi\u00f3 la Licencia (y Por Qu\u00e9<\/a> Duele)<\/h2>\n
Lo Que el Cambio de Licencia Significa en la Pr\u00e1ctica Para Tu Proyecto<\/h2>\n
non-free<\/code>. Si tu pipeline de CI\/CD instala Redis desde los repos del sistema, ya est\u00e1s afectado aunque no lo sepas.<\/p>\nValkey 8.x: Lo Que<\/a> Me Sorprendi\u00f3 Despu\u00e9s de<\/a> Migrar<\/h2>\n
redis-cli<\/code> por valkey-cli<\/code> es literalmente todo lo que<\/a> necesit\u00e9 hacer en la mayor\u00eda de mis scripts de utilidad.<\/p>\n# Verificar versi\u00f3n y algunas m\u00e9tricas nuevas en Valkey 8.x\nvalkey-cli INFO server | grep -E "valkey_version|io_threads_active"\n\n# Output que vi en mi setup:\n# valkey_version:8.0.2\n# io_threads_active:4\n\n# En Redis 7.4, el mismo campo ser\u00eda redis_version\n# y io_threads no est\u00e1 activo por defecto de la misma manera\n<\/code><\/pre>\nDos Semanas Migrando en Producci\u00f3n:<\/a> Lo que Realmente<\/a> Pas\u00f3<\/h2>\n
# El cambio m\u00e1s invasivo en c\u00f3digo fue esto \u2014 casi ninguno\nimport redis # El cliente de Python sigui\u00f3 funcionando sin cambios\n\nr = redis.Redis(\n host='valkey-primary.internal', # Solo cambi\u00e9 el hostname\n port=6379,\n decode_responses=True\n)\n\n# Todo lo dem\u00e1s igual. ZADD, HGET, SETEX, Pub\/Sub \u2014 sin cambios.\nr.zadd('leaderboard', {'user:1042': 9850.5})\nscore = r.zscore('leaderboard', 'user:1042')\n<\/code><\/pre>\nredis-py<\/code> 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 \u2014eso era un requisito del fork desde el d\u00eda uno.<\/p>\nkill -9<\/code> en el primario un viernes<\/a> a las<\/a> 4pm porque pens\u00e9 que ten\u00edamos tiempo suficiente para resolver problemas antes del fin de semana), el tiempo de elecci\u00f3n del nuevo primario fue m\u00e1s lento de lo esperado \u2014unos 35 segundos vs los ~8 segundos que ve\u00eda con Redis Sentinel.<\/p>\nsentinel down-after-milliseconds<\/code>. El valor por defecto en mi instalaci\u00f3n nueva de Valkey era diferente al que ten\u00eda en Redis. Cinco minutos de config fix, problema resuelto. Pero me cost\u00f3 esa tarde de viernes.<\/p>\nMi Veredicto: Cu\u00e1ndo Elegir Cada Uno (Sin Rodeos)<\/h2>\n