Valkey 9 : le fork Redis redéfinit le cache cloud après 18 mois

Depuis octobre 2025, Valkey 9 traite plus d’un milliard de requêtes par seconde au sein du cluster et a remplacé Redis comme solution par défaut dans les principaux services de cache managés. Après 18 mois, ce fork de licence est devenu un projet technologiquement autonome, tandis que Redis 8 ne rattrape que partiellement ce retard.

À retenir

• Vitesse de forkage: Huit jours après l’annonce de la Redis SSPL en mars 2024, Valkey était sous l’égide de la Linux Foundation, soutenue par AWS, Google, Oracle, Alibaba, Ericsson, Huawei et Tencent (TechCrunch, 2024).
• Valkey 9 GA: Disponible depuis le 21 octobre 2025. Un cluster gère plus d’un milliard de requêtes par seconde, le débit d’un seul nœud augmente jusqu’à 40 % par rapport à Valkey 8.1 (Linux Foundation, 2025).
• Par défaut dans le cloud: AWS ElastiCache et Google Memorystore ont fait de Valkey la norme pour les nouvelles instances. Valkey enregistre environ un million de pulls de conteneurs par semaine (The Stack, février 2026).
• Contre-offensive de Redis 8: En mai 2025, Redis Labs a sorti la version 8 avec un tri-licensing (RSALv2, SSPLv1, AGPLv3) – retour vers l’open source, mais sous copyleft plutôt que BSD.
• Migration: Le passage de Redis 7.2 à Valkey est décrit par les mainteneurs comme un « patch sans heurts ». AWS propose des mises à niveau sur place sans temps d’arrêt.

18 mois de Valkey : du fork de protestation au standard par défaut

Le 20 mars 2024, Redis Labs est passé de la licence BSD à la Server Side Public License (SSPLv1) – une mesure visant à contrer les hyperscalers qui vendaient Redis en tant que service managé sans contribuer au projet. Huit jours plus tard, Valkey, un fork de Redis 7.2.4, était disponible sur GitHub, avec Madelyn Olson (AWS, ancienne mainteneuse de Redis) comme figure de proue et la Linux Foundation comme organisation parrainante.

Ce qui a commencé comme une protestation contre la licence est devenu, 18 mois plus tard, une base de code indépendante. Valkey 8.0 a introduit le threading I/O à la fin de 2024, Valkey 8.1 a amélioré les handshakes TLS d’environ 300 %. Valkey 9.0 est sorti en version générale (GA) le 21 octobre 2025 – avec migration atomique des slots, expiration des champs de hachage et support multi-bases de données en mode cluster. Aucune de ces fonctionnalités n’existe dans Redis 8 sous une forme comparable.

La structure de soutien est inhabituellement large : outre AWS, Google, Oracle, Alibaba, Ericsson, Huawei et Tencent figurent comme sponsors corporatifs sur le site web de Valkey. Pour un projet d’infrastructure, il s’agit d’une alliance rare – et une différence marquée par rapport aux forks dépendant d’un seul fournisseur. Ceux qui connaissent l’histoire d’OpenStack, MariaDB ou OpenTofu le savent : la gouvernance multi-fournisseurs sous une fondation neutre est le facteur clé pour la stabilité à long terme d’un fork. Un seul fournisseur peut changer ses priorités à tout moment, tandis qu’un consortium de sept géants de la tech a des contrepoids intégrés.

Sous le capot, l’équipe Valkey a également structuré la propriété du code différemment de Redis sous l’ancien modèle. Les revues se font via un tableau public de mainteneurs, et les patches proviennent des ingénieurs d’AWS, Google et Alibaba à des fréquences similaires. Ce n’est pas une garantie de meilleure qualité de code, mais un fondement plus stable contre les décisions stratégiques individuelles. Ceux qui se demandaient en 2024, lors de l’annonce de la SSPL, si une telle étape pourrait se répéter, trouvent dans cette structure de gouvernance la réponse la plus claire de l’industrie.

Valkey 9 vs. Redis 8 : où se situent les véritables différences

L’erreur la plus fréquente dans ce débat consiste à croire qu’il ne s’agit que de licence. Sur le plan technique, les deux projets ont divergé depuis octobre 2025 – et ces différences impactent directement les charges de travail en production.

Sources : valkey.io, redis.io, AWS Database Blog, Google Cloud Blog (2025-2026)

Le point décisif réside dans la migration atomique des slots. Le resharding classique de Redis Cluster génère brièvement des erreurs de redirection côté client, interprétées comme des timeouts dans les environnements à forte charge. Valkey 9 déplace les slots sans interruption ni erreur client – une fonctionnalité particulièrement cruciale pour les clusters de cache multi-locataires.

Les chiffres derrière la controverse des benchmarks

Les deux projets vantent des gains de performance et les chiffres sont exacts. Redis 8 annonce jusqu’à 87 % de commandes plus rapides par rapport à Redis 7.4 et jusqu’à un doublement du débit. Valkey 9, quant à lui, annonce jusqu’à 40 % de débit en plus par rapport à Valkey 8.1 – et dépasse pour la première fois la barre du milliard de requêtes.

Celui qui souhaite comparer les deux chiffres tombe dans un piège. Redis 8 se compare à sa propre version précédente 7.4 au niveau des nœuds individuels. Valkey 9 mesure la scalabilité au niveau du cluster. Le seul point de comparaison fiable est celui des benchmarks indépendants – et ceux-ci confirment jusqu’à présent la tendance de Valkey : dans le benchmark MaiCoin, Valkey 8.0.1 a atteint des valeurs de débit plus élevées et des latences p99 meilleures que Redis 7.1.0 avec un matériel identique.

Pour les équipes qui doivent prendre une décision aujourd’hui, l’indicateur le plus important n’est pas le pourcentage, mais la vitesse des fonctionnalités. Valkey a livré trois versions majeures en 18 mois. Redis 8 était le retour à la bannière open source, mais pas encore la preuve d’un rythme de publication durable.

Sous le capot de Valkey 9 se trouvent trois innovations techniques qui jouent un rôle plus important dans les benchmarks que le chiffre officiel de débit. Le Memory Prefetching pour les commandes de pipeline permet d’obtenir un débit jusqu’à 40 % plus élevé pour les opérations groupées. Les Zero-Copy-Responses pour les grandes réponses économisent jusqu’à 20 % de surcharge, car les données ne sont plus copiées entre le noyau et l’espace utilisateur. Et les optimisations SIMD pour BITCOUNT et HyperLogLog rendent certaines requêtes analytiques jusqu’à 200 % plus rapides. Ces trois optimisations visent les charges de travail que les utilisateurs de Redis connaissent depuis des années comme des goulots d’étranglement – les analyses sur les champs binaires, les agrégations en temps réel, les grandes pipelines dans les tâches par lots.

Ce que font les fournisseurs de cloud maintenant

Les courbes d’adoption les plus claires proviennent des hyperscalers. AWS a publié ElastiCache for Valkey dès 2024, faisant de Valkey la valeur par défaut pour les nouveaux clusters et offrant un chemin de mise à niveau géré pour les installations Redis existantes. Google Cloud a déclaré Memorystore for Valkey 9.0 comme version GA, et Oracle OCI a lancé son propre service géré avec OCI Cache. Dans les trois cas, « Valkey par défaut » signifie que si vous ne vous opposez pas activement, vous obtiendrez Valkey, et non Redis.

Les chiffres d’adoption confirment cette tendance. Selon les données actuelles de Docker Hub, Valkey enregistre environ 1 million de pulls de conteneurs par semaine, soit plus de 70 millions depuis le fork. Ce n’est pas un indicateur d’utilisation productive, mais un indicateur fiable de l’intégration dans les pipelines CI/CD, le développement local et les déploiements Kubernetes. Pour un projet âgé de 18 mois, cette densité d’intégration est remarquable.

Un cas concret issu de la pratique d’ElastiCache : l’exchange de crypto-monnaies taiwanais MaiCoin a effectué une mise à niveau Blue-Green de Redis OSS vers Valkey et a mesuré Redis 7.1.0, Valkey 7.2.6 et Valkey 8.0.1 sous une charge identique. Le résultat : Valkey 8.0.1 a fourni le débit le plus élevé, la latence p99 la plus basse et la meilleure efficacité mémoire. Pour une charge de travail productive avec des exigences de latence strictes, ce n’est pas un jeu de chiffres marketing, mais un argument de coût concret.

Le marché DACH (Allemagne, Autriche, Suisse) réagit plus prudemment, mais de manière compréhensible. Les grandes environnements Kubernetes gérés sur AWS Frankfurt et Google Cloud Frankfurt déploient désormais Valkey 9 pour les nouveaux clusters, tandis que les installations existantes tournent souvent encore sous Redis 7.x. Cela correspond au schéma typique du marché DACH : la question de la licence est clarifiée, la migration suit lors du prochain cycle de planification de capacité – rarement dans la panique, souvent coordonnée avec les branches de release ou les mises à niveau planifiées des clusters.

Migration : ce que signifie « patch sans couture » en pratique

Valkey 9 parle le protocole Redis (RESP) et prend en charge les clients Redis 7.2 sans modification. C’est la raison principale pour laquelle la migration se déroule souvent sans adaptation du code. AWS ElastiCache propose un chemin de mise à niveau managée In-Place : de nouveaux nœuds Valkey sont déployés dans le cluster existant, répliquent à partir du Redis-Primary, puis un basculement est effectué. Temps d’arrêt : zéro.

Dans la réalité, trois écueils peuvent survenir. Premièrement : les modules Redis-Stack comme RedisJSON, RediSearch ou RedisBloom sont propriétaires et ne sont pas inclus dans Valkey. Ceux qui les utilisent doivent soit opter pour les modules communautaires Valkey (Valkey-JSON, Valkey-Search, Valkey-Bloom, tous sous licence BSD), soit rester avec Redis. Les modules communautaires sont fonctionnels, mais n’ont pas le même niveau de fonctionnalités que les variantes Redis-Stack.

Deuxièmement : ceux qui utilisent des fonctionnalités Redis Enterprise comme la réplication géo-active Active-Active ne trouvent pas d’équivalent dans Valkey. Ces charges de travail restent avec Redis ou migrent vers des alternatives comme Dragonfly ou KeyDB.

Troisièmement : les outils d’observabilité qui analysent les champs INFO spécifiques à Redis nécessitent parfois des ajustements. Les grands fournisseurs d’APM (Datadog, Grafana, New Relic) prennent en charge Valkey de manière native, mais les tableaux de bord personnalisés peuvent rencontrer des problèmes.

Quand rester avec Redis – et quand changer

La décision est moins technique qu’organisationnelle. Ceux qui utilisent Redis Enterprise ou Redis Stack Module en production n’ont pas de chemin de migration pragmatique – et Redis 8 sous AGPLv3 est juridiquement sans problème pour la plupart des cas d’utilisation, tant que le code n’est pas revendu comme service à des tiers. La viralité de l’AGPL ne s’applique pas aux opérations internes.

En revanche, ceux qui utilisent Redis comme un cache classique clé-valeur, qui utilisent des services managés sur AWS ou Google Cloud et qui n’ont pas besoin de fonctionnalités Enterprise, sont aujourd’hui techniquement mieux lotis avec Valkey 9. La licence est plus permissive, la vitesse des fonctionnalités est plus élevée, l’intégration cloud est plus approfondie. Et le risque qu’un grand fournisseur cloud cesse son soutien est beaucoup moins probable pour un projet avec sept sponsors corporatifs sous la Linux Foundation que pour un fournisseur commercial unique.

Pour les équipes qui démarrent en 2026, la question est déjà tranchée : AWS ElastiCache et Google Memorystore génèrent Valkey, et non Redis, pour les nouveaux clusters. Ceux qui veulent Redis doivent explicitement conclure un contrat commercial.

Conclusion

Après 18 mois de débat, la question de la licence est tranchée – non pas parce qu’un camp a perdu, mais parce que les deux parties ont abouti à des options stables. Valkey 9 est la solution par défaut techniquement plus active et sous licence permissive des grands fournisseurs de cloud. Redis 8 est de nouveau open source sous la licence AGPLv3 et offre des gains de performance, mais ne suit pas le rythme des sorties de Valkey.

Pour la majorité des workloads cloud dans les régions DACH (Allemagne, Autriche, Suisse), Valkey 9 représente aujourd’hui le choix le moins risqué. Ceux qui migrent devraient commencer par un cache non critique, évaluer les modules communautaires de Valkey et utiliser les options de mise à niveau in-place du service managé respectif. Le « patch sans heurts » convient dans 80 % des cas – les 20 % restants nécessitent du temps de planification, mais sans surprises.

Questions fréquentes