Redis vs Valkey: qué cambió después del fork

En marzo de 2024, Redis Ltd. cambió la licencia de Redis de BSD a dual RSALv2/SSPL. El mensaje fue claro: el uso comercial en la nube sin pagar licencia queda restringido. La comunidad open source reaccionó como siempre reacciona: fork. Nació Valkey, bajo la Linux Foundation, con licencia BSD de nuevo.

Dos años después, ¿qué pasó? ¿Migrar vale la pena?

Lo que no cambió

A nivel de protocolo, Valkey 8.x es compatible con Redis 7.2. Tus clientes existentes (redis-py, ioredis, lettuce) funcionan sin cambios. Los comandos, la estructura de datos, los módulos principales (Streams, Pub/Sub, Lua scripting) — todo funciona igual.

La migración técnica es un rename del binario y un cambio de connection string. Nada más.

Lo que sí cambió

Rendimiento en operaciones específicas

Valkey introdujo optimizaciones en el threading modelo que Redis no tiene. En benchmarks propios con cargas de trabajo de lectura intensiva (caché de API, sessiones), vimos mejoras del 15-20% en throughput con Valkey 8.1 vs Redis 7.2.

# Benchmark con redis-benchmark (compatible con Valkey)
redis-benchmark -t set,get -n 100000 -c 50

# Resultado Redis 7.2: ~120k ops/sec
# Resultado Valkey 8.1: ~145k ops/sec

Pero ojo — en workloads de escritura pesada (colas, counters), la diferencia es mínima (< 5%). Y en operaciones con transacciones MULTI/EXEC, Redis todavía tiene una ligera ventaja por optimizaciones específicas del pipeline.

Ecosistema de módulos

Acá es donde Redis todavía gana. Redis Search, RedisJSON, RediSearch — los módulos “oficiales” de Redis Ltd. no existen en Valkey. Valkey tiene alternativas comunitarias, pero la madurez es menor.

Si tu arquitectura depende de RediSearch para búsqueda full-text o RedisJSON para documentos JSON nativos, migrar a Valkey requiere evaluar alternativas:

• RediSearch → Meilisearch, Typesense, o OpenSearch
• RedisJSON → JSON serializado en strings (con overhead de parseo)

Soporte y estabilidad

Redis Ltd. ofrece soporte enterprise. Valkey tiene el respaldo de la Linux Foundation pero no tiene un “número de soporte” al que llamar. Para startups y empresas medianas, esto no importa. Para enterprises con SLAs estrictos, es un factor.

Nuestra decisión

Migramos tres servicios a Valkey:

1. Caché de API — migrado, sin problemas, mejor rendimiento
2. Sesiones de usuario — migrado, transparente
3. Cola de background jobs — NO migrado (depende de BullMQ que tiene tight coupling con Redis)

La migración nos tomó una tarde. El mayor riesgo no fue técnico sino operativo: monitoreo, alertas, y dashboards tuvieron que actualizarse para soportar el nuevo nombre.

¿Cuándo migrar?

• Migrá a Valkey si: usás Redis como caché, session store, o pub/sub simple. El rendimiento es mejor y la licencia es más permisiva.
• Quedate en Redis si: dependés de módulos enterprise (RediSearch, RedisJSON), necesitás soporte comercial, o usás herramientas con tight coupling a Redis (BullMQ, algunos ORMs).
• Evaluá otras opciones si: tu caso de uso es búsqueda full-text (usá Meilisearch) o documentos JSON (usá MongoDB o PostgreSQL con JSONB).

La fragmentación de la comunidad de Redis es un síntoma de un problema más grande: la tensión entre open source y SaaS no se resuelve con licencias. Se resuelve con modelos de negocio que alineen incentivos. Pero eso es tema para otro post.