En deux ans, le paquet redis de votre distribution a peut-être changé de mainteneur, de licence et de nom sans que vous ayez touché à quoi que ce soit. Sur une Fedora 42 ou une Debian 13, taper apt install redis peut installer Valkey. Le binaire répond au même protocole, écoute le même port, parle le même redis-cli, mais ce n'est plus le même projet. Voici comment on en est arrivé là, et ce que ça implique quand on opère un cache ou un store en mémoire en production.
Le feuilleton des licences, version courte
Mars 2024 : Redis Inc. abandonne la licence BSD 3-clause qui tenait depuis quinze ans et bascule sur un double modèle source-available, RSALv2 et SSPLv1, à partir de Redis 7.4. Motif officiel : les fournisseurs cloud revendaient Redis en service managé sans rien reverser. La SSPL interdit d'offrir le logiciel en service managé, la RSALv2 interdit d'en faire un produit concurrent. Aucune des deux n'est reconnue open source par l'OSI.
Huit jours plus tard, la Linux Foundation annonce Valkey, un fork parti de Redis 7.2.4, sous BSD 3-clause, avec AWS, Google Cloud, Oracle, Ericsson et Snap derrière. Les mainteneurs partis de chez Redis suivent. Le fork garde la licence permissive que Redis venait d'abandonner.
Puis volte-face. Salvatore Sanfilippo, le créateur de Redis, revient dans l'entreprise fin 2024. Le 1er mai 2025, Redis 8.0 sort en ajoutant l'AGPLv3 au choix de licences. Sanfilippo titre sobrement « Redis is open source software again » et reconnaît que la SSPL n'a jamais été acceptée par la communauté. Redis redevient donc open source, mais sous une licence copyleft forte, deux ans après être parti, et après avoir laissé le temps à un fork concurrent de prendre racine.
AGPLv3, ce n'est pas BSD : le point juridique qui compte
Le retour de Redis à l'open source est réel, mais il faut lire la licence. L'AGPLv3 est copyleft fort : si vous modifiez Redis et que vous l'exposez à des tiers via le réseau, vous devez publier vos modifications sous AGPL. Pour la plupart des gens qui font tourner un Redis stock comme cache, ça ne change rien. Pour un éditeur qui patche le serveur, ou qui l'embarque dans un produit propriétaire accessible en SaaS, le service juridique va vouloir regarder de près. C'est exactement le genre de clause qui fait fuir certaines DSI par principe, indépendamment du risque réel.
Valkey reste sous BSD 3-clause. Permissive, sans obligation de reversement, sans question à poser au légal. Pour beaucoup d'équipes, c'est l'argument qui tranche avant même de parler de performance : on ne veut plus jamais revivre un changement de licence imposé en cours de route.
La compatibilité, en pratique
Valkey est parti de Redis 7.2.4 avec un objectif de compatibilité au niveau du protocole RESP et des commandes. Concrètement, un Valkey 7.2 est un remplacement direct d'un Redis 7.2 : même format de RDB et d'AOF, même réplication, même redis-cli (renommé valkey-cli, avec un alias). Les clients applicatifs (jedis, lettuce, redis-py, ioredis, go-redis) parlent à l'un comme à l'autre sans modification.
La divergence commence après. Redis 8 a réintégré sous AGPL des types de données et modules qui étaient auparavant à part, et continue sa propre feuille de route. Valkey avance de son côté, avec sa propre numérotation. Les deux restent largement interopérables sur le cœur, mais l'écart fonctionnel se creusera avec le temps. Si vous dépendez d'un module spécifique de l'écosystème Redis, vérifiez avant. Si vous utilisez Redis comme cache, file ou session store classique, la bascule est triviale : on arrête le service, on remplace le binaire, on redémarre sur les mêmes fichiers de données.
Pour les architectures plus sérieuses, la migration suit la même logique qu'un changement de version majeur. Sur un déploiement répliqué façon cluster Redis avec Sentinel, on bascule les réplicas un par un avant le master, RDB et AOF étant lisibles par les deux moteurs. Sur un cluster Redis shardé, le slot mapping et le protocole de cluster sont conservés, ce qui permet un remplacement nœud par nœud.
Performances : le multithreading des deux côtés
C'est l'argument que tout le monde agite, et c'est là qu'il faut se méfier des chiffres balancés sans contexte. Les deux projets ont attaqué la même limite historique : un Redis classique traite les commandes sur un seul thread, le réseau devenant le goulot avant le CPU sur les grosses machines.
Valkey 8.0 a introduit un threading des I/O réseau asynchrone, avec répartition des tâches d'entrée-sortie sur plusieurs cœurs tout en gardant la manipulation des données monothread. Les chiffres annoncés par le projet sont spectaculaires : environ 1,19 million de requêtes par seconde sur une instance AWS c7g.4xlarge (Graviton3, 16 vCPU), contre 360 000 pour Valkey 7.2 sur la même base. Redis 8 a répondu avec son propre modèle de threading I/O amélioré, avec des gains de throughput mesurés jusqu'à plus de 100 % selon le paramétrage io-threads.
Qui gagne ? Ça dépend du benchmark, et c'est honnête de le dire. Des mesures indépendantes de Momento sur c8g.2xlarge donnent Valkey 8.1 devant Redis 8 sur l'écriture, avec un meilleur p99. D'autres bancs, dont ceux publiés par Dragonfly, mettent Redis 8 en tête sur l'ensemble des scénarios testés. La vérité opérationnelle : les deux ont rattrapé leur retard sur le multithreading I/O, l'écart résiduel se joue sur le workload exact, le hardware et le réglage. Personne ne devrait migrer pour un différentiel de throughput qui se mesure en pourcents et qui s'inverse selon la machine. Si la latence est votre vrai sujet, le réglage de l'éviction et de la persistance pèse plus lourd que le choix du fork, comme détaillé dans nos patterns de caching Redis.
Qui a gagné l'écosystème en 2026
Sur le terrain, le fork a pris l'avantage là où ça compte pour un ops : le packaging par défaut. Fedora 42, Ubuntu 26.04 LTS, Debian 13 en backports et Arch pointent désormais sur Valkey. Arch a sorti Redis de son dépôt officiel vers l'AUR dès avril 2025, un mois avant l'annonce du retour de Redis à l'open source. Quand la distribution décide à votre place, l'inertie joue pour Valkey : c'est ce que vous obtenez en installant le paquet, c'est ce qui reçoit les mises à jour de sécurité du mainteneur distribution.
Côté cloud, AWS, Google et Oracle proposent Valkey en service managé, souvent positionné moins cher que l'équivalent Redis, ce qui était précisément le grief de départ de Redis Inc. La boucle est bouclée : la licence visait à empêcher les hyperscalers de monétiser Redis sans contribuer, le résultat est qu'ils monétisent Valkey en y contribuant.
Ce qu'on fait, concrètement
La règle qu'on applique : pour un déploiement neuf, on part sur Valkey. C'est le paquet par défaut de la distribution, la licence BSD ne pose aucune question, la compatibilité est totale et le projet est porté par une fondation, pas par une entreprise qui peut rechanger d'avis. Pour un Redis existant en 7.2 ou 7.4 qui tourne bien, pas d'urgence à migrer dans la nuit : on planifie la bascule sur la prochaine fenêtre de maintenance, on teste la restauration des RDB et AOF sur une instance Valkey de prérecette, on valide les clients, puis on remplace.
On ne reste sur Redis 8 que dans un cas précis : une dépendance réelle à une fonctionnalité spécifique de sa feuille de route post-fork, et une équipe juridique à l'aise avec l'AGPL. Sinon, le sens du courant est clair, et il va vers le fork. Le vrai risque n'a jamais été technique. Il était contractuel, et c'est lui qui a fait basculer les distributions.
Migrer un store en mémoire critique sans coupure, ça se prépare comme n'importe quel changement de moteur en production : inventaire des clients, test de restauration, bascule réplica par réplica, rollback documenté. Si votre cache porte des sessions ou une file de traitement et que la bascule vous inquiète, c'est typiquement le genre d'opération qu'on cadre et exécute en infogérance sans interruption de service.
Sources
- Redis is open source again, par antirez : l'annonce du créateur de Redis sur le retour à l'AGPLv3 et l'aveu d'échec de la SSPL.
- Redis Returns to Open Source under AGPL License: Is It Too Late?, InfoQ : analyse du changement de mai 2025 et de l'avance prise par Valkey.
- Redis 8.0 vs. Valkey 8.1: A Technical Comparison, Dragonfly : comparatif technique des modèles de threading et des benchmarks.
- Valkey Turns One, Momento : benchmarks indépendants et état de l'adoption.
- Licenses, Redis : la page officielle des licences Redis (RSALv2, SSPLv1, AGPLv3).


