Dragonfly: el caché moderno inspirado en Redis

Actualizado: 2026-05-03

Dragonfly cumple tres años como alternativa compatible con el protocolo de Redis, y en 2025 ya se puede hablar de ella con datos en mano y no solo con los anuncios del lanzamiento. La conversación ha cambiado: hace dos años la pregunta era si iba a sobrevivir al empuje de Redis, y ahora la pregunta es si tiene sentido desplegarlo de serie para ciertos patrones.

Puntos clave

• Dragonfly usa arquitectura multihilo shared-nothing con un hilo por shard de datos — un nodo de 8 núcleos aprovecha los 8, mientras que Redis solo usa 1.
• El algoritmo de snapshot sin fork mantiene la latencia plana mientras persiste — en cargas de decenas de GB es la diferencia entre un pico visible cada pocos minutos y una línea plana.
• La compatibilidad con el protocolo Redis es sólida para los casos estándar (BullMQ, Sidekiq, cachés PHP) — los bordes aparecen en módulos dinámicos como RedisSearch y RedisJSON.
• El patrón donde Dragonfly gana con claridad es el caché denso: un nodo de 128 GB y 16 núcleos puede reemplazar un clúster Redis de 4–6 nodos.
• Desde que Valkey nació como fork de Redis 7.2 bajo la Linux Foundation (Apache 2.0), la decisión es entre tres opciones: Dragonfly, Redis oficial o Valkey — el factor determinante suele ser la licencia más que el rendimiento puro.

Lo que hace distinto a Dragonfly

Redis ha sido el referente durante más de una década, y su modelo de un solo hilo por nodo es intencional: evita bloqueos y simplifica el razonamiento sobre atomicidad. Dragonfly parte del mismo modelo de comandos y de la misma interfaz de red, pero por dentro es un sistema multihilo con arquitectura shared-nothing. Cada hilo gestiona su propio trozo de datos y la coordinación entre hilos se hace mediante paso de mensajes, no mediante locks compartidos.

El efecto práctico es que un nodo Dragonfly con ocho núcleos puede aprovechar los ocho, mientras que un nodo Redis tradicional solo usa uno y deja el resto del equipo ocioso. Para cargas ligeras eso no importa: un Redis sobrado aguanta decenas de miles de peticiones por segundo en un solo núcleo. Para cargas densas, con picos de cientos de miles de peticiones por segundo, Dragonfly permite mantener menos nodos, cada uno mejor aprovechado, a costa de una configuración algo más sensible al tamaño del equipo.

El otro gran cambio arquitectural es la forma de hacer snapshots. Redis clona el proceso con fork para volcar memoria a disco, lo cual funciona bien en equipos pequeños pero degrada la latencia cuando la memoria usada es grande, porque el sistema operativo tiene que duplicar páginas cuando cambian. Dragonfly implementa un algoritmo de snapshot propio que no depende de fork, con lo que la latencia se mantiene mientras se persiste. Esto parece un detalle, pero en cargas de varias decenas de gigabytes es la diferencia entre un pico visible de latencia cada pocos minutos y una línea plana.

Compatibilidad real con Redis

Dragonfly se anuncia como un reemplazo drop-in del protocolo de Redis, y en 2025 esa afirmación es mucho más sólida que en 2022. Los comandos principales están cubiertos, las estructuras de datos habituales funcionan, y la mayor parte de los clientes oficiales de Redis se conectan sin cambios. He probado lectores de BullMQ, colas de Sidekiq y cachés de aplicaciones PHP contra Dragonfly y el cambio fue transparente en los tres casos.

Donde aparecen los bordes es en funcionalidades menos centrales pero críticas para ciertos entornos:

• La replicación con el protocolo nativo de Redis funciona pero con limitaciones en topologías complejas.
• Redis Streams están soportados pero algunos consumidores muy específicos detectan diferencias sutiles.
• Las extensiones mediante módulos dinámicos — como RedisSearch o RedisJSON — no se cargan: Dragonfly implementa parte de esa funcionalidad de forma nativa, con su propio soporte para búsqueda y JSON, pero con API ligeramente distinta.

Si tu aplicación depende de un módulo concreto, toca verificar con calma antes de migrar. La misma lógica de “verificar antes de comprometerse” aplica cuando se evalúa Redis 8.2 vectorial frente a motores dedicados.

Casos donde compensa

Después de ver varios despliegues, el patrón donde Dragonfly se come a Redis es el caché denso. Un solo nodo Dragonfly con 128 gigabytes de memoria y dieciséis núcleos puede reemplazar un pequeño clúster de Redis con cuatro o seis nodos, simplificando la operación y reduciendo el coste de infraestructura de forma apreciable.

El segundo caso es el de picos de tráfico impredecibles. Con Redis tradicional, una subida repentina de escrituras puede saturar el único hilo y generar colas. Con Dragonfly, la carga se reparte entre hilos y la degradación es más suave. Esto importa especialmente en comercios electrónicos con campañas puntuales, en plataformas de medios con virales impredecibles o en APIs públicas con tráfico irregular.

El tercer caso, menos obvio, es el de persistencia con estado grande. Si tu caso de uso requiere recargar millones de claves después de un reinicio, la diferencia de velocidad en snapshots y recuperación puede ahorrar minutos de indisponibilidad por despliegue.

Donde sigue siendo prudente quedarse con Redis

No todo son ventajas. Hay tres escenarios donde seguiría eligiendo Redis, o ahora Valkey:

1. El equipo ya tiene experiencia profunda con Redis y herramientas internas construidas alrededor. Cambiar de motor por una ganancia marginal no compensa el coste de formación y de reescribir scripts operativos.
2. La aplicación depende de módulos como RedisSearch, RedisTimeSeries o RedisGraph en su versión oficial. Aunque Dragonfly tenga equivalentes, la paridad funcional todavía no es total.
3. Clientes empresariales que contratan soporte comercial directo. Redis Ltd. y ahora Valkey a través de la Linux Foundation ofrecen canales de soporte maduros con SLAs. Dragonfly tiene soporte comercial a través de Dragonfly Labs, pero el ecosistema de partners y la profundidad de la comunidad todavía no son comparables.

El factor Valkey en la ecuación

Desde marzo de 2024, con el cambio de licencia de Redis a RSAL y SSPL y el nacimiento de Valkey bajo la Linux Foundation, la comparación ya no es solo Dragonfly contra Redis. Valkey es un fork directo de Redis 7.2 con gobernanza abierta y licencia BSD, y en 2025 las grandes nubes públicas han ido migrando sus ofertas gestionadas hacia Valkey.

Mi lectura a día de hoy:

• Para despliegues nuevos sin inercia: Dragonfly merece estar en la lista corta.
• Para despliegues existentes sobre Redis abierto: Valkey es el camino de menor fricción.
• Para despliegues existentes sobre versiones comerciales de Redis: la decisión depende más de la relación con el proveedor que de un dato técnico concreto.

Mi lectura

Dragonfly ha madurado hasta el punto de ser una opción defendible y no un experimento. Su arquitectura multihilo encaja con cargas densas y con equipos modernos, y su algoritmo de snapshot sin fork resuelve un problema real que Redis arrastra desde su origen. Pero no es una bala de plata: el ecosistema de Redis, su comunidad y su soporte comercial siguen siendo ventajas reales que tardan en construirse.

La recomendación práctica es probarlo en un entorno de staging con una copia de tráfico real antes de tomar decisiones definitivas. Las métricas de ahorro suelen ser llamativas, pero los bordes de compatibilidad solo aparecen cuando se prueba de verdad. Y en cachés, los bordes raros son los que rompen producción en un mal momento.

Por ahora, en jacar.es mantengo Redis 8 en la infraestructura principal por inercia y por el peso del ecosistema, pero estoy mirando con interés un servicio auxiliar donde la densidad de caché justifica probar Dragonfly en serio. Si esa prueba sale bien, esta conversación cambia en los próximos meses. Integrar las métricas de latencia de caché en el stack de Parca, Beyla y Grafana sería el siguiente paso natural para medir el impacto real del cambio.