Valkey : la meilleure solution de remplacement open-source prête à l'emploi pour Redis
En mars 2024, Redis Inc. est passé de sa licence BSD permissive à RSALv2/SSPLv1, générant une véritable exposition aux risques de conformité pour les équipes d'ingénierie commerciale.
En réponse, la communauté OSS et les utilisateurs ont presque immédiatement forké Redis vers une nouvelle option appelée Valkey. Lancé le même mois par la Linux Foundation, Valkey offre une véritable solution de remplacement prête à l'emploi, permettant d’éviter les contraintes juridiques introduites par Redis.

Remplacer Redis sans reconstruire vos applications
La réponse des communautés au changement de licence de Redis a été de rechercher des options rapides, coordonnées et bien pourvues en ressources. En résumé, il s’agit d’un fork issu des communautés. Valkey n'est pas un fork de protestation avec peu de soutien. Bénéficiant d'un soutien institutionnel important et d'un développement actif, Valkey est donc une alternative entièrement sous licence BSD, parfaitement compatible avec la base de code Redis que la plupart des équipes utilisent déjà.

Valkey : la tranquillité d’esprit intégrée au projet et au service
Pourquoi les développeurs cherchent-ils une alternative à Redis en 2026 ?
Les raisons du changement de licence de Redis en 2024
Pendant la majeure partie de son existence, Redis a été distribué sous licence BSD 3-Clause, l'une des licences open source les plus permissives. Vous pouviez utiliser, modifier et élaborer des produits commerciaux sur la base de Redis sans restriction. Tout cela a changé le 20 mars 2024, quand Redis Inc. a annoncé que Redis 7.4 et toutes les futures versions fonctionnelles passeraient à un modèle à double licence : RSALv2 (Redis Source Available License v2) et SSPLv1 (Server Side Public License). Aucune de ces licences n'est approuvée par l'Open Source Initiative (OSI), et toutes deux imposent des restrictions explicites sur la manière dont le logiciel peut être utilisé dans des environnements commerciaux et cloud.
En quoi la licence SSPL crée-t-elle un risque de conformité pour les produits commerciaux ?
La licence SSPL a été initialement créée par MongoDB pour empêcher les fournisseurs de services cloud d'offrir des services de base de données gérés sans contribuer en retour. Le problème fondamental pour les équipes chargées des produits commerciaux est l’article 13 : si votre application est mise à disposition en tant que service et si elle s’appuie sur un logiciel sous licence SSPL, vous pourriez être tenu(e) de publier le code source de l'intégralité de votre pile de services, y compris les composants propriétaires que vous avez développés.
Pour la plupart des équipes d'ingénierie, cette obligation est rédhibitoire en cas de développement de fonctionnalités et d'alternatives. Même si vos conseillers juridiques déterminent que le risque est faible en pratique, l'incertitude suffit à créer des frictions concernant les achats, les revues de sécurité et les contrats clients d'entreprise. La licence RSALv2 aggrave cette situation en interdisant explicitement l'utilisation dans des fonctionnalités ou produits concurrents, donnant à Redis Inc. une grande discrétion quant à ce qui constitue de la concurrence... et laissant à nouveau les utilisateurs de Redis exposés à un risque complexe de contestations judiciaires. Ces difficultés peuvent facilement être évitées en utilisant du code régi par une licence approuvée par l'OSI.
Rester sur Redis 7.2 : la dette de sécurité cachée
La dernière version de mise en cache Redis sous BSD était la version 7.2. Certaines équipes choisissent de rester sur cette version, plutôt que d'accepter les nouvelles modalités de la licence. Il s’agit probablement d’une décision pragmatique à court terme, mais elle présente un coût à long terme. Redis 7.2 ne reçoit plus de correctifs de sécurité ni de corrections de bugs de la part de Redis Inc., ce qui signifie que toutes les CVE découvertes après le changement de licence restent non traitées sur cette branche. Pour les équipes exploitant la mise en cache Redis 7.2 dans un environnement de production, traitant des données sensibles ou intervenant dans des cadres tels que NIS2 ou SOC 2, il ne s'agit pas d'un risque théorique. Le fait de rester sur Redis 7.2 crée un écart de conformité actif qui s'accentue à chaque mois qui passe.
Les raisons pour lesquelles l'AGPLv3 pour Redis 8.0 n'est pas une troisième option
Avec la sortie de Redis 8.0 en 2025, Redis Inc. a de nouveau évolué en matière de licences, cette fois vers l'AGPLv3, qui est approuvée par l'OSI. Il s'agit d'un véritable pas en avant concernant la légitimité open source, et cela répond à l'une des critiques clés exprimées lors du changement de 2024. Cependant, l'AGPLv3 est une licence copyleft forte, introduisant ses propres complications pour les équipes commerciales.
Tout logiciel interagissant avec un composant sous licence AGPLv3 via un réseau peut déclencher une obligation de publier le code source de ce logiciel sous la même licence. Pour les produits SaaS propriétaires, cela reste une contrainte importante pour les alternatives. Plusieurs personnalités reconnues dans le secteur, dont des contributeurs au projet Valkey, ont noté que l'AGPLv3 (bien qu’elle s’appuie sur davantage de principes que la licence SSPL) place toujours Redis dans une catégorie différente des alternatives open source véritablement permissives.
Préserver le comportement des applications et contrôler l'emplacement des données
Les configurations multi-nœuds peuvent également préserver des modèles de résilience familiers. La compatibilité nécessite toujours des tests. Les modules, les comportements spécifiques à une version et les combinaisons de commandes inhabituelles peuvent produire une réponse différente. La conception du stockage, les paramètres des clients et la topologie peuvent également affecter la stabilité ou le débit. Aucune migration ne doit partir du principe que chaque cas marginal s'exécutera plus rapidement ou se comportera de manière identique. La licence approuvée par l'OSI de Valkey offre aux équipes commerciales une alternative open source durable à Redis, sans soumettre l'architecture des applications à des conditions restrictives.
Le choix du déploiement ajoute ensuite une dimension opérationnelle. Une offre européenne managée peut combiner le traitement par fils d’exécution, le placement résilient des nœuds et l'hébergement contrôlé des données. Cette approche contribue à la souveraineté européenne des données en gardant l’emplacement, l'accès et la gestion contractuelle visibles, tout en réduisant l'administration courante de la plateforme.

DragonflyDB arrive en tête concernant le débit brut sur un seul nœud dans certains tests, mais cet avantage diminue considérablement dans les configurations en cluster. La parité fonctionnelle avec Redis 7.2 est complète, et la feuille de route de Valkey a depuis ajouté des améliorations du multi-threading et des gains d'efficacité mémoire qui, dans certaines charges de travail, le placent devant la version dont il est issu.
D'autres technologies peuvent répondre à des besoins spécialisés, tels que la recherche vectorielle ou les charges de travail sans serveur intermittentes. Les recherches peuvent inclure des documents techniques trouvés via Google, des discussions communautaires et la documentation des fournisseurs, mais la documentation principale et les tests contrôlés doivent occuper une place plus importante. Comparez chaque alternative en fonction des modifications des applications, de la maturité opérationnelle, du support disponible, de la gouvernance et de l'effort total de migration. La technologie appropriée est celle qui répond aux exigences mesurées avec des risques opérationnels et de licence acceptables.
Adaptez le modèle opérationnel à vos besoins
Solution Valkey managée
Les Databases for Valkey managées conviennent aux entreprises qui souhaitent des opérations simples et un coût d'infrastructure prévisible. OVHcloud gère la haute disponibilité, la maintenance, la surveillance et les sauvegardes, réduisant le travail interne nécessaire pour exécuter un service résilient. La bande passante et les IOPS incluses facilitent également la budgétisation. Il s'agit d'une solution par défaut pratique lorsque les équipes des plateformes ont besoin de disposer de Valkey sans avoir à gérer toutes les tâches opérationnelles.
Solution Valkey autogérée
L'autogestion permet de contrôler les versions logicielles, la topologie, les paramètres de sécurité et l'emplacement de déploiement. Elle peut convenir aux entreprises ayant des besoins spécifiques ou des opérations de base de données établies. Les inconvénients sont tout aussi réels : l'équipe interne est responsable des montées en charge, des sauvegardes, de l'observabilité, des tests de failover et des interventions en cas d’incident. Les ressources communautaires peuvent aider, mais elles ne remplacent pas une capacité opérationnelle ou un support de production responsable.
KeyDB
KeyDB peut convenir aux équipes envisageant l'exécution multithread pour des charges de travail de données en mémoire particulières et des objectifs de latence. Évaluez la compatibilité, l'activité de publication, la santé du projet et le support disponible avant de vous engager. Faites une analyse comparative avec l'application réelle plutôt que de supposer qu'une fonctionnalité architecturale améliorera chaque modèle de requête. Les informations associées à des fondateurs ou à une déclaration initiale de projet doivent également être vérifiées par rapport à la documentation actuelle.
Alternatives spécialisées
Les services sans serveur peuvent réduire la planification de la capacité pour les charges de travail intermittentes, tandis que les bases de données vectorielles prennent en charge la recherche de similarité et d'autres modèles de données spécialisés. Des logiciels en mémoire alternatifs peuvent cibler des besoins spécifiques en matière de débit ou de persistance. Ces outils permettent de résoudre des problèmes définis, mais ne constituent pas nécessairement des solutions prêtes à l’emploi. Tenez compte des modifications des applications, du déplacement des données, de la responsabilité opérationnelle et du coût à long terme avant de les préférer à Valkey.
Choisissez un chemin de migration adapté à vos temps d'arrêt
Mettez hors service votre instance Redis pour assurer la cohérence, copiez le fichier dans votre répertoire de données Valkey, démarrez Valkey, et le tour est joué. Le temps total de migration est proportionnel à la taille de l’ensemble de données, et non à la complexité des applications. Pour les environnements de production dans lesquels les temps d'arrêt ne sont pas acceptables, la réplication en direct est la voie la plus sûre. Valkey peut être configuré comme réplique d'une instance Redis 7.2 en cours d'exécution en utilisant la commande standard REPLICAOF.
Une fois la réplication entièrement synchronisée, vous pouvez mettre à jour la chaîne de connexion de votre application pour pointer vers Valkey, la promouvoir en tant que primaire, et mettre hors service l'instance Redis. Les deux systèmes utilisant le même protocole de réplication, ce processus est fonctionne bien et a été testé en production par des équipes chez tous les principaux fournisseurs de cloud.
![[object Object]](https://assets.ovhcloud.com/1fiX676v6wSp4t82zXEm6hhry_sNzAzOTNmMTIyZWVkYzg0/555a10a6-71ae-4d77-959e-b2a8dc0e9831_ima_c8d0550b.png)
Mettre en place un cadre de préparation à la migration en quatre parties
1. Compatibilité des applications
Créez un inventaire de chaque commande, bibliothèque de client et version de protocole utilisée. Enregistrez les fonctionnalités RESP3, les scripts Lua, les transactions, les modèles Pub/Sub, les dépendances JSON ou de module, et le comportement spécifique à l'application concernant les délais d’attente. Un cœur compatible ne signifie pas que chaque extension se comportera de la même manière. Comparez l'environnement actuel avec la version cible et testez des requêtes représentatives. Incluez la gestion des échecs, le regroupement de connexions et la logique de nouvelle tentative. Si une application repose sur une technologie fournie par un plugin externe, vérifiez séparément son état de maintenance. Cet inventaire transforme une compatibilité générale en preuves fondées sur vos besoins spécifiques.
2. Protection de l'intégrité des données
Mesurez l'ensemble de données avant la migration, y compris le nombre de clés, la répartition des expirations, la taille des objets et la consommation de mémoire de pointe. La cible nécessite suffisamment de mémoire pour le fonctionnement normal, la réplication et une surcharge temporaire pendant la synchronisation ou la persistance. Examinez les paramètres de snapshot et d'ajout seul, plutôt que de les copier sans les analyser. Après le transfert, comparez le nombre de clés, les valeurs échantillonnées et le comportement d'expiration. Les vérifications au niveau des applications peuvent révéler des problèmes qui n’ont pas été relevés par les totaux bruts, tels que des sessions mal formées ou un état de file d'attente incomplet. Communiquez les critères d'acceptation aux responsables des services avant le basculement, afin que chacun utilise la même définition d'un ensemble de données valide.
3. Cartographie de la topologie cible
Documentez si la plateforme actuelle est autonome, répliquée ou distribuée sur un cluster. Enregistrez chaque nœud, route de réseau, règle de sécurité, dépendance DNS et emplacement physique. Cette carte aidera les équipes à sélectionner une disposition cible reflétant les besoins de résilience plutôt que de reproduire des choix historiques. Les tests de connectivité doivent couvrir l'application, les systèmes de surveillance et les outils d'administration. Pour une charge de travail distribuée, vérifiez la gestion des emplacements, le placement des répliques et le comportement en cas de perte d'un nœud. Les exigences de localisation des données peuvent également déterminer les régions ou zones de disponibilité acceptables.
4. Contrôle du basculement
Établissez des bases de référence pour la latence, le taux d'erreur et les ressources avant de déplacer le trafic. Définissez les seuils de surveillance, les critères de retour en arrière et les responsables des décisions pendant que le service est stable. Cela évite aux équipes de s’interroger sur les comportements acceptables lors d'un incident. Transférez le trafic par étapes lorsque l'architecture le permet. Commencez par des charges de travail internes ou à faible risque, observez les erreurs clients et comparez les résultats, puis montez en puissance. Veillez à ce que la source reste récupérable jusqu'à ce que la validation soit terminée. Un basculement sûr s’appuie sur des preuves mesurées, des responsabilités claires et une procédure de retour en arrière, et non uniquement sur de déclarations de compatibilité.
Pourquoi choisir OVHcloud Managed Databases for Valkey ?
L'une des frustrations persistantes avec les bases de données managées dans le cloud est l'imprévisibilité de la facture. Pensez aux frais qui augmentent en cas de charge, car la bande passante, les IOPS et le stockage de sauvegarde sont mesurés séparément. Le modèle de tarification d'OVHcloud regroupe ces coûts dans un tarif mensuel forfaitaire. La bande passante, les opérations d'E/S et les sauvegardes automatisées sont incluses, de sorte que le coût que vous voyez lors du provisionnement correspond à celui que vous payerez en production. Pour les équipes financières et d'achats d’entreprises en croissance gérant des budgets d'infrastructure serrés, cela rend la planification de la capacité nettement plus simple.
