Valkey 9 GA : ce que le fork cache signifie pour les équipes ops DACH 18 mois après la scission Redis

La communauté Valkey a publié la version 9 le 14 avril 2026 – 18 mois après le fork de Redis 7.4 sous l’égide de la Linux Foundation. Valkey dispose pour la première fois d’un historique de versions propre, qui va sur le fond au-delà de la simple compatibilité Redis. Pour les équipes ops DACH, la question n’est plus « si » mais « quand » et dans quel ordre la migration se fait.

En lienCloud Repatriation 2026 : le modèle TCO  /  Broadcom-VMware Channel : le paysage des prestataires 2026

Ce qu’apporte concrètement Valkey 9

La release apporte trois catégories de changements. Nouvelles fonctionnalités : transport RDMA pour la réplication cluster dans les scénarios haut débit, gestion ACL améliorée avec intégration Active Directory et une interface de scripting retravaillée qui reprend les scripts Lua sans breaking changes. Sous le capot : I/O threading plus performant, qui montre dans les benchmarks de la Linux Foundation environ 20 pour cent de gain de débit sur les workloads read-heavy par rapport à Redis 7.4. Enfin, propreté de la licence : tout sous BSD-3, aucune clause SSPL.

Dans l’environnement entreprise DACH, deux points sont pertinents. Premièrement, la licence BSD : elle autorise des cas d’usage où la SSPL de Redis 8 aurait bloqué les validations internes – par exemple dans des secteurs fortement régulés comme la banque et la santé. Deuxièmement, la disponibilité managée chez AWS : ElastiCache for Valkey offre jusqu’à 33 pour cent d’avantage tarifaire par rapport à ElastiCache for Redis OSS. Pour les équipes avec des clusters cache à plusieurs dizaines de nœuds, cela se traduit vite par des économies annuelles à cinq chiffres.

Valkey 9 face à Redis 8

Les deux stacks coexistent en 2026. Qui choisit entre les deux le fait rarement pour des raisons techniques – le plus souvent par licence et considérations commerciales. Les différences en synthèse :

Ce que coûte concrètement la migration

Pour les clusters Redis existants, le passage à Valkey est dans la plupart des cas un exercice de rolling replacement. Les données restent compatibles, les fichiers de persistance (RDB, AOF) peuvent être réutilisés sans export/import. En pratique, cela signifie : reconfigurer la topologie de réplication, remplacer nœud par nœud, laisser la configuration client en place. L’effort se situe pour un setup typique à trois nœuds dans la fourchette de quelques jours-personnes, le vrai travail étant la refonte du monitoring et des règles d’alerte qui attendent des noms de métriques spécifiques à Redis.

La décision intéressante n’est plus Valkey contre Redis. C’est Valkey contre les fonctions Redis Stack qui ne sont volontairement pas reprises dans la version OSS. Qui utilise Bloom Filters, graphes ou time series doit vérifier quels modules Valkey ou alternatives conviennent.

Le point qui devient désagréable, ce sont les modules commerciaux Redis Stack : RedisGraph, RedisTimeSeries, RedisBloom et RediSearch. Qui les utilise en production trouve actuellement dans Valkey soit des alternatives communautaires à maturité variable, soit doit basculer vers des services externes. La Linux Foundation a annoncé que Valkey Modules disposerait d’un écosystème d’extensions stable d’ici le T3 2026 – d’ici là, la migration de ces cas d’usage est le vrai projet, pas le remplacement de cache en lui-même.

Pour qui le basculement vaut la peine

Trois groupes ont en 2026 un business case clair. Premièrement, les entreprises de secteurs régulés, pour lesquelles la licence SSPL bloque les validations OSS internes – banques, assureurs, KRITIS santé. Deuxièmement, les clients AWS avec de grands clusters cache, où l’avantage tarifaire de 33 pour cent devient matériel. Troisièmement, les équipes qui développent depuis l’écosystème open source et dépendent d’un support communautaire à long terme.

Pour tous les autres : la migration n’est pas un cas d’urgence. Qui exploite Redis 7.2 ou 7.4 dans un setup Managed Service stable n’a pas à sauter tout de suite. Le bon moment est la prochaine grande refonte d’infrastructure ou la prochaine fenêtre de négociation contractuelle avec le fournisseur cloud. Valkey 9 est disponible dès maintenant – mais un exploitation parallèle complète pour tester ne vaut que rarement l’effort.

Questions fréquentes

Mon client Redis existant fonctionne-t-il sans modification contre Valkey 9 ?

Oui, à condition que le client ne s’appuie pas sur des extensions Redis 8. Le protocole wire est identique, les commandes standard sont rétrocompatibles. Dans Spring Data, Node-Redis, redis-py, go-redis et Jedis, le basculement se fait sans changement de code – seule l’URL de connexion pointe ailleurs.

Qu’en est-il de RedisSearch, RedisGraph, RedisTimeSeries et RedisBloom ?

Ces modules Stack sont propriétaires Redis Inc. et ne tournent pas dans Valkey. La Linux Foundation travaille à des Valkey Modules pour Vector, Search et TimeSeries – le niveau de maturité varie. Qui s’appuie en production sur ces modules doit planifier la migration comme un sous-projet distinct, pas comme un remplacement de cache.

AWS ElastiCache for Valkey est-il réellement rentable ?

Sur des caches single-node de petite taille, le montant absolu reste limité. L’avantage tarifaire de 33 pour cent devient matériel sur des clusters Multi-AZ avec plusieurs instances r7g ou r7gd. Un cluster typique à six nœuds r7g.large économise par an une somme du bas de la tranche à cinq chiffres – suffisant pour justifier une migration interne.

Y a-t-il des arguments de conformité en faveur de Valkey dans les audits DACH ?

Oui. BSD-3 est de l’open source conforme OSI, la SSPL de Redis 8 ne l’est pas. Dans les comités OSS internes des banques, assureurs et administrations, Redis 8 est écarté par le filtre SSPL, Valkey le franchit. Qui dépend d’une politique OSS interne a avec Valkey moins de débats à mener.

Source image de couverture : Pexels / panumas nikhomkhai (px:1148820)