DragonflyDB : un seul gros nœud plutôt qu'un cluster Redis shardé

Un Redis qui tourne sur une machine à 32 cœurs en utilise un seul pour traiter les commandes. Les 31 autres regardent passer le train. On compense en shardant : on découpe le keyspace sur plusieurs instances, on empile les nœuds, et on hérite d'un cluster à opérer, à superviser et à rééquilibrer. DragonflyDB attaque le problème par l'autre bout : faire tenir tout ce que ferait ce cluster dans un seul binaire qui sature les 32 cœurs. C'est un pari d'architecture, pas un coup de peinture sur Redis, et il vaut la peine d'être compris avant de l'envisager en prod.

Petit rappel de périmètre : on ne va pas remettre une pièce dans le feuilleton des licences Redis. Ce dossier est traité à part dans notre comparatif Valkey contre Redis. Ici, le sujet c'est l'architecture multi-thread et ce qu'elle change concrètement quand on opère un store en mémoire.

Dragonfly remplace la boucle d'événements monothread historique par un modèle thread-per-core. Chaque thread porte son propre moteur d'exécution et possède une tranche distincte du keyspace, appelée shard. Une clé donnée appartient à un seul thread, qui est seul à la lire et à l'écrire. C'est l'architecture shared-nothing : pas de structure partagée entre les threads, donc pas de verrou à poser pour protéger les accès concurrents.

L'intérêt est précisément là. Le coût qui tue le multithreading naïf d'un store en mémoire, c'est la contention sur les verrous : plus on ajoute de cœurs, plus ils passent de temps à s'attendre. En partitionnant les données par thread, Dragonfly supprime la cause à la racine. Le débit monte avec le nombre de cœurs au lieu de plafonner. Pour les commandes multi-clés, le moteur route la requête vers les threads concernés et coordonne, mais le chemin nominal mono-clé reste sans verrou.

Côté ops, ça inverse la logique de dimensionnement. Avec Redis, ajouter du CPU à la VM ne sert quasiment à rien pour le throughput d'une instance : le thread principal est le plafond, et on scale en lançant d'autres process. Avec Dragonfly, on donne une grosse machine et le binaire l'utilise. Le scaling vertical redevient un levier réel.

Dragonfly parle le protocole RESP, le format de sérialisation de Redis. Conséquence directe : les clients applicatifs existants (jedis, lettuce, redis-py, ioredis, go-redis) se connectent sans modification. On change l'endpoint dans la config, le code ne bouge pas. Le projet annonce la compatibilité avec environ 185 à 240 commandes Redis selon les versions, ce qui couvre l'écrasante majorité des usages cache, file, session et compteurs.

Il supporte aussi le protocole Memcached en plus de RESP, avec toutes les commandes Memcached à l'exception de cas. Un point à valider si vous arrivez d'un parc Memcached : le check-and-set n'est pas couvert, et c'est exactement le genre de détail qui se découvre en prod si on ne lit pas la doc avant.

Drop-in ne veut pas dire identique sur toute la surface. Si votre application dépend d'un module de l'écosystème Redis (les types et modules réintégrés côté Redis, par exemple), vérifiez la couverture avant de migrer. Pour un usage standard, la bascule est triviale. Pour un usage exotique, c'est un audit de commandes à mener, pas une promesse marketing à gober.

Deux choix internes expliquent pourquoi Dragonfly tient plus de données sur la même RAM, et c'est là que l'architecture paie au-delà du throughput brut.

D'abord la structure de stockage. Là où Redis utilise sa table de hachage classique avec ses dictEntry, Dragonfly s'appuie sur une structure maison nommée dashtable, dérivée du papier de recherche « Dash: Scalable Hashing on Persistent Memory ». Le principe : un répertoire de pointeurs vers des segments, chaque segment étant une mini-table de hachage de taille constante en adressage ouvert. Résultat annoncé par le projet : environ 20 bits de métadonnées par entrée contre 64 bits côté Redis, et un répertoire négligeable (de l'ordre de 9600 octets pour un million d'items). La dashtable permet aussi un redimensionnement incrémental et un scan sans état, ce qui évite les à-coups de latence sur les grosses bases.

Ensuite le snapshot. C'est probablement l'argument le plus solide pour un ops. Redis sauvegarde en forkant le process et en s'appuyant sur le copy-on-write : tant que peu de pages sont modifiées, ça va, mais sur une base très active pendant un BGSAVE, chaque écriture recopie une page et la consommation mémoire peut doubler au pic. C'est le piège qui fait swapper ou tuer le process par l'OOM killer en pleine sauvegarde, au pire moment.

Dragonfly fait sans fork. SAVE et BGSAVE passent par le même algorithme entièrement asynchrone. Chaque shard-thread sérialise ses propres données et un système de versions garantit un point dans le temps cohérent : avant de démarrer, le shard capture son epoch courant, et seules les entrées dont la version est antérieure à ce cut sont écrites, sans doublon et sans figer les écritures concurrentes. Les I/O disque passent par io_uring pour ne pas bloquer le reste. Conséquence mesurée par l'éditeur : pas d'augmentation visible de la mémoire pendant le snapshot, là où Redis grimpait jusqu'à près de 3 fois la conso de Dragonfly au pic. À traiter comme un chiffre éditeur, pas comme une garantie universelle, mais le mécanisme, lui, est réel et c'est ce qui compte.

Le claim qui circule partout, c'est le « 25x ». Soyons précis sur ce qu'il recouvre et d'où il vient. Il s'agit d'un benchmark de l'éditeur, sur une instance AWS très réseau-capable (c6gn.16xlarge), comparant Dragonfly à un Redis en process unique, où Dragonfly dépasse 3,8 millions de requêtes par seconde. Le facteur 25 vient en grande partie de la comparaison contre un seul process Redis : sur une machine à 64 vCPU, un Redis monothread part forcément battu, puisqu'il n'exploite qu'un cœur.

C'est un chiffre vendeur, à manier avec des pincettes. Comparer un binaire multi-thread à un process monothread sur une grosse machine, c'est comparer ce qui est conçu pour scaler verticalement à ce qui ne l'est pas. La vraie question opérationnelle n'est pas « combien de fois plus vite qu'un Redis unique », mais « combien de nœuds Redis ce Dragonfly remplace, et à quel coût d'exploitation ». La règle qu'on applique : aucun chiffre éditeur ne remplace un bench sur votre workload, votre hardware et votre ratio lecture/écriture. Le throughput annoncé est un plafond de labo, pas une promesse de prod.

Voilà le cas d'usage qui justifie de regarder Dragonfly. Vous avez un cluster Redis shardé monté uniquement pour dépasser le plafond d'un cœur unique. Pas pour la résilience géographique, pas pour répartir la charge sur plusieurs sites : juste pour empiler du CPU et de la RAM que Redis ne sait pas exploiter dans un seul process. Ce cluster, vous le payez en complexité : slot mapping, rééquilibrage, protocole de gossip, supervision de N nœuds, gestion des resharding.

Dragonfly propose de tasser tout ça dans une instance qui sature une grosse machine. Le projet revendique des workloads de l'ordre du téraoctet et plus d'un million de requêtes par seconde en vertical sur un seul nœud. Si votre cluster existait seulement pour contourner le monothread, une instance Dragonfly verticale supprime la raison d'être du cluster, et avec elle une bonne part de la charge d'exploitation. Moins de nœuds à patcher, à superviser, à débugger à 3h du matin.

Ce n'est pas un argument valable dans tous les cas. Si votre cluster Redis répond à un vrai besoin de haute disponibilité multi-nœuds ou de distribution géographique, le single-node ne le remplace pas. Et le réglage fin de l'éviction et de la persistance, qui pèse souvent plus lourd que le moteur lui-même sur la latence ressentie, reste votre travail quel que soit le store, comme on le détaille dans nos patterns de caching.

Dragonfly n'est pas un remplacement universel, et le vendre comme tel serait malhonnête.

Le single-node a longtemps été le modèle dominant, et c'est cohérent avec la thèse du scaling vertical : un nœud, gros, simple à raisonner. Le mode cluster existe et distribue les clés à la façon de Redis Cluster, mais avec une nuance opérationnelle importante. Dragonfly fournit le data plane (le serveur), pas le control plane : le monitoring de santé des nœuds, le failover automatique, la migration de slots pour rééquilibrer ne sont pas dans le serveur. Ces fonctions arrivent via l'offre cloud de l'éditeur (Dragonfly Swarm, annoncé en 2025, qui vise au-delà de 100 To et 100 M req/s). En self-hosted pur, le control plane HA, c'est à vous de l'assembler. À chiffrer dans la décision : ce que vous économisez en simplifiant le sharding, vous pouvez le repayer en plomberie HA si vous restez hors cloud éditeur.

L'écosystème est plus jeune. Redis traîne quinze ans d'outillage, de retours de prod, de réponses sur les forums pour le moindre cas tordu. Dragonfly est solide mais récent : moins de kilomètres au compteur, une communauté plus petite, et des fonctionnalités qui se construisent encore. Pour un store critique, la maturité de l'écosystème compte autant que les benchmarks.

Enfin la licence. Dragonfly est publié sous Business Source License 1.1, pas sous une licence OSI. Concrètement : vous pouvez l'utiliser et le modifier librement tant que vous ne vendez pas un service de store en mémoire concurrent basé dessus. La licence bascule automatiquement en Apache 2.0 quatre ans après chaque version. Pour un usage interne, en cache ou en datastore de votre propre produit, c'est sans friction. Pour un éditeur qui voudrait en faire un service managé, c'est précisément ce que la BSL interdit. À faire valider par votre légal si votre modèle s'en approche, comme pour toute licence source-available.

Dragonfly a du sens dans un cas net : un cluster Redis monté uniquement pour franchir le mur du monothread, sur des volumes qui tiennent sur une seule grosse machine, en usage interne. Là, le gain est réel et double : moins de nœuds à opérer, une RAM mieux exploitée grâce à la dashtable et au snapshot sans fork. C'est un vrai levier de simplification d'infra, pas un gadget.

Pour le reste, on reste prudent. Un Redis ou un Valkey qui tourne bien, dans un écosystème mature, avec une licence OSI et une HA déjà en place, n'a aucune raison de migrer pour un chiffre de bench. Le single-node ne remplace pas une vraie distribution multi-site. Et le « 25x » est un plafond de labo contre un process monothread, pas un engagement sur votre prod. Avant toute bascule : bench sur votre workload, test de restauration du snapshot, validation des commandes utilisées, plan de rollback. Le moteur change, la méthode de mise en prod ne change pas.

Migrer un store en mémoire critique sans coupure, ça se cadre comme tout changement de moteur sous charge : inventaire des clients, bench grandeur nature, bascule réversible, supervision pendant la fenêtre. Si votre cache porte des sessions ou une file de traitement et que l'opération vous inquiète, c'est typiquement ce qu'on pilote en infogérance sans interruption de service.

• dragonflydb/dragonfly, GitHub : dépôt officiel, README, architecture shared-nothing et compatibilité Redis/Memcached (source éditeur).
• Dashtable, documentation Dragonfly : description technique de la structure de hachage et de l'empreinte mémoire (source éditeur).
• Dragonfly Point-in-Time Snapshotting Design : algorithme de snapshot sans fork, versioning par epoch, io_uring (source éditeur).
• License, Dragonfly : Business Source License 1.1, restriction service managé, bascule Apache 2.0 à 4 ans (source éditeur).
• Database of Databases, Dragonfly : fiche sur dbdb.io, l'annuaire de bases de données de Carnegie Mellon, modèle de données et positionnement.