En mars 2024, un changement de licence de Redis a provoqué une réorganisation importante de son écosystème. Quelques jours plus tard, Valkey a été annoncé : un nouveau projet issu du code de Redis, avec une licence permissive et une gouvernance communautaire. Pour les entreprises, les agences et les équipes de développement, cette séparation a soulevé une question pratique : faut-il conserver Redis, passer à Valkey ou choisir un autre service de données ?
La réponse dépend de ce que l’application demande réellement à son stockage. Accélérer un site, conserver une session, compter des opérations et coordonner une réservation ne sont pas des besoins équivalents. Deux services peuvent tous les deux stocker des paires « clé-valeur » et offrir des garanties très différentes.
Cette analyse revient sur les événements de 2024, puis distingue les évolutions ultérieures et les options cloud documentées pour cette édition.
Qu’est-ce qu’un stockage clé-valeur ?
Un stockage clé-valeur fonctionne comme un dictionnaire : une clé permet de retrouver une valeur. Une application pourrait associer catalogue:accueil:fr au résumé du catalogue affiché sur sa page d’accueil. Elle connaît la clé à demander ; elle n’a pas nécessairement besoin d’effectuer une recherche dans plusieurs tables.
Ce modèle devient particulièrement utile lorsque la même information est consultée souvent. Au lieu de recalculer un résultat à chaque visite, l’application peut en conserver une copie temporaire. C’est le principe d’un cache. La base de données principale reste alors la référence, tandis que le cache évite une partie du travail répétitif.
Une durée de vie, souvent appelée TTL pour time to live, limite le temps pendant lequel une entrée reste utilisable. Avec Redis, la commande SET peut associer une valeur à une clé et prévoir son expiration. Le choix de cette durée appartient à l’application : une information qui change rarement et un état de stock ne tolèrent pas le même retard. La documentation de SET décrit ces options.
Trois questions comptent davantage que le mot « KV » :
- Fraîcheur : combien de temps une ancienne valeur peut-elle rester visible ?
- Coordination : que se passe-t-il si plusieurs utilisateurs modifient la même donnée en même temps ?
- Récupération : peut-on reconstruire la donnée, ou faut-il absolument la conserver après une panne ?
Un cache de catalogue peut être reconstruit. Une commande payée, elle, exige un système de référence et une récupération dont les garanties sont adaptées à l’activité.
Redis : un serveur de structures de données, au-delà du simple cache
Redis est souvent présenté comme un cache en mémoire, mais son modèle est plus riche qu’un dictionnaire de textes. Il propose notamment des chaînes, des tables de champs, des listes, des ensembles, des ensembles triés et des flux d’événements. Ces structures permettent d’exprimer directement certains besoins applicatifs : un compteur, un classement ou un historique consommé par plusieurs traitements. Les fonctionnalités exactes dépendent de la version et de l’offre utilisées. Voir les types de données Redis et leur comparaison par usage.
Pour une équipe, l’intérêt réside autant dans les opérations disponibles que dans la vitesse d’accès. « Lire un nombre, ajouter un, réécrire le résultat » dans trois requêtes indépendantes peut produire un résultat incorrect lorsque deux traitements interviennent simultanément. Une opération serveur adaptée peut éviter cette course. Il faut néanmoins distinguer une commande atomique, un groupe de commandes et une transaction métier complète.
La proximité réseau reste déterminante. Un service très rapide placé loin de l’application peut ajouter une latence perceptible à chaque échange. Le nombre d’allers-retours, la taille des valeurs et les pointes de charge doivent donc faire partie de l’évaluation, au même titre que le moteur.
Ce qui s’est passé entre Redis et Valkey en 2024
Le changement de licence de Redis
Le 20 mars 2024, Redis a annoncé que les versions à partir de Redis 7.4 seraient proposées sous deux licences au choix : RSALv2 et SSPLv1, en remplacement de la licence BSD à trois clauses pour ces nouvelles versions. L’annonce présentait ce changement comme une réponse au modèle économique de la distribution de Redis, notamment dans le cloud. C’est la position de l’éditeur, à distinguer d’un jugement sur tous les acteurs concernés. Annonce originale de Redis
Ce changement ne signifiait pas que les installations existantes allaient cesser de fonctionner. Il ne transformait pas non plus rétroactivement les versions déjà diffusées sous BSD. Redis a notamment précisé la situation des versions antérieures et des prestataires de services dans sa communication du 29 mars 2024.
La naissance de Valkey
Le 28 mars 2024, la Linux Foundation a annoncé Valkey, issu de Redis 7.2.4, avec une licence BSD à trois clauses et un développement communautaire. Un fork désigne ici une nouvelle trajectoire de développement à partir d’un code existant. Il ne s’agissait donc pas d’un moteur entièrement réécrit ni d’un simple nouveau nom commercial de Redis. Annonce de la Linux Foundation
Le 28 mars correspond à l’annonce du projet. La première version stable Valkey 7.2.5 a été annoncée le 16 avril 2024. Cette distinction compte lorsqu’on reconstitue la chronologie. Annonce de Valkey 7.2.5
Licence, gouvernance et service commercial : trois sujets différents
La licence définit les permissions et les conditions d’utilisation du code. La gouvernance décrit la manière dont le projet prend ses décisions. Le service commercial précise ce qu’un fournisseur exploite, facture et prend en charge pour son client.
Ces dimensions peuvent évoluer séparément. Un logiciel libre peut être vendu comme service géré. Un code consultable publiquement n’est pas nécessairement distribué sous une licence reconnue comme open source. Et choisir une licence permissive ne dispense pas d’exploiter correctement le service.
Pour une entreprise qui héberge ou redistribue un moteur, le bon réflexe consiste à vérifier la licence de la version exacte et le mode de fourniture envisagé. Une décision de conformité ne devrait pas reposer sur le seul nom « Redis » ou sur un résumé de blogue.
Ce qui a changé depuis : Redis 8 et la poursuite de Valkey
Le 1er mai 2025, Redis a ajouté AGPLv3 comme troisième option de licence avec Redis 8, à côté de RSALv2 et SSPLv1. Il serait donc incomplet d’écrire aujourd’hui que Redis a simplement « quitté l’open source » sans expliquer cette évolution. Cela ne constitue toutefois pas un retour à BSD : les conditions d’une licence à copyleft et celles d’une licence permissive diffèrent. Annonce de l’option AGPLv3
Le tableau officiel des licences Redis distingue les générations de versions. Il faut aussi séparer le moteur et ses licences des conditions contractuelles d’un service commercial.
Valkey a continué son propre développement : Valkey 8.0 a été annoncé en septembre 2024, puis Valkey 9.0 en octobre 2025. Les projets partagent une origine, mais leurs fonctionnalités et leurs trajectoires ne sont pas figées dans l’état du fork initial. Valkey 8.0, Valkey 9.0
Valkey peut-il remplacer Redis sans changement ?
Dans certains environnements, la transition est relativement directe. Cela ne justifie pas une promesse générale de remplacement « sans aucune modification ».
La documentation Valkey décrit sa compatibilité avec Redis OSS 7.2 et les versions antérieures, notamment au niveau du protocole RESP. Elle précise aussi que les fichiers de données produits par Redis CE 7.4 et les versions ultérieures ne sont pas compatibles avec Valkey. Une connexion cliente compatible ne prouve donc pas qu’une sauvegarde, un module ou toutes les commandes d’une version plus récente sont transférables. Guide officiel de migration vers Valkey
Avant de choisir une méthode de migration, il faut examiner la version de départ, le client utilisé par l’application, les scripts, les modules, le mode cluster et les données à préserver. Un cache que l’on peut vider puis reconstruire demande un plan différent d’un stockage contenant des sessions ou des traitements en attente.
La même prudence s’applique au retour arrière. Une fois de nouvelles écritures acceptées par le système cible, revenir simplement à une ancienne copie peut perdre ces écritures. Le plan doit préciser comment traiter cette période, et pas uniquement comment changer une adresse de connexion.
Les options cloud : remplacer le moteur ou changer d’architecture ?
Un service géré peut réduire le travail d’installation, de mise à jour ou de surveillance. Il ne dispense pas de vérifier les fonctionnalités, la configuration, les responsabilités et les limites du contrat choisi.
Des offres comme Amazon ElastiCache et Google Cloud Memorystore for Valkey permettent d’utiliser Valkey dans un environnement géré. L’offre Redis Cloud fournit également Redis sous forme de service géré. Le moteur disponible, sa version, la topologie, les régions et les mécanismes de récupération doivent être vérifiés pour le service retenu ; le nom de la famille de produits ne suffit pas.
Pour une application serverless, un service tel qu’Upstash propose aussi un client HTTP/REST pour son service compatible avec l’API Redis. Cette méthode d’accès peut être pratique dans un Worker, mais elle ne prouve pas la prise en charge de toutes les commandes ou de tous les comportements Redis. La compatibilité annoncée doit être confrontée aux usages réels.
Une autre option consiste à répartir les besoins entre plusieurs services spécialisés. C’est particulièrement pertinent sur une plateforme comme Cloudflare : KV, Durable Objects, D1, R2 et Queues ne sont pas plusieurs marques du même moteur. Ils répondent à des fonctions différentes.
| Besoin principal | Famille à examiner | Point à vérifier en premier |
|---|---|---|
| Conserver une application qui utilise des commandes Redis | Redis ou Valkey, géré ou auto-hébergé | Compatibilité de la version, des commandes et des données |
| Mettre en cache des résultats simples et reconstructibles | Cache applicatif, Memcached ou cache HTTP selon le cas | Invalidation, expiration et reconstruction |
| Lire très souvent des valeurs peu modifiées depuis plusieurs régions | Stockage KV distribué | Retard de propagation acceptable |
| Coordonner les modifications d’un même objet métier | Service de coordination ou stockage transactionnel adapté | Atomicité et périmètre des garanties |
| Interroger des données structurées et liées | Base relationnelle | Requêtes, transactions et modèle de données |
| Conserver des fichiers ou exécuter des tâches en différé | Stockage objet ou file de messages | Durabilité, reprises et sémantique de livraison |
Cette grille est une aide au raisonnement, pas une équivalence technique entre les produits. Memcached, par exemple, vise le cache de valeurs simples en mémoire ; il ne fournit pas automatiquement les structures et le protocole attendus par une application Redis.
Cloudflare Workers KV : distribuer les lectures, en acceptant la propagation
Workers KV conserve des valeurs qui peuvent être mises en cache sur le réseau de Cloudflare. Il convient notamment aux lectures nombreuses de données qui changent peu. Il offre une cohérence à terme : une modification peut prendre jusqu’à 60 secondes, ou davantage selon le cache, avant d’être visible ailleurs. Même la visibilité immédiate au lieu de l’écriture n’est pas garantie. Fonctionnement de Workers KV
Ce compromis peut convenir à une configuration de présentation ou à un contenu dont un léger retard est acceptable. En revanche, notre conclusion architecturale serait différente pour une révocation d’accès urgente, une réservation unique ou un compteur devant être exact : une ancienne valeur peut alors changer le résultat métier.
La FAQ documente aussi une limite d’écriture par clé pour l’API de liaison Workers. Il faut vérifier ce type de limite, ainsi que la mise en cache des lectures, avant de remplacer un usage Redis comportant beaucoup de modifications de la même clé. FAQ Workers KV
Workers KV n’est pas un serveur Redis compatible avec ses commandes. Adapter une application à cette API constitue un changement d’architecture, avec ses propres tests. Le fait de stocker des clés et des valeurs ne garantit ni le même protocole ni les mêmes opérations atomiques. La présentation de l’API Workers KV permet de voir cette différence d’interface.
Les autres briques Cloudflare, et leur rôle
Durable Objects : coordonner un état précis
Un Durable Object associe une identité, du code et du stockage à un objet logique. Son stockage offre des garanties de cohérence forte dans son périmètre. Cela permet d’organiser des décisions autour d’une même entité, comme une salle collaborative ou un compteur partagé. Ce n’est pas une transaction globale automatique entre tous les objets de l’application. Un état gardé uniquement en mémoire doit être enregistré dans le stockage persistant pour survivre à un redémarrage. Présentation des Durable Objects
Un exemple de conception serait d’envoyer les opérations concernant une même ressource vers son objet responsable. Le développeur doit encore définir les règles, gérer les erreurs et vérifier les limites de charge. Placer toutes les opérations de l’entreprise dans un seul objet créerait une concentration de responsabilités à évaluer.
D1 : conserver un modèle relationnel
D1 propose une base SQL gérée reposant sur SQLite. C’est une famille pertinente lorsque l’application a besoin de tables et de requêtes structurées, plutôt que d’un simple accès par clé. Pour utiliser la réplication en lecture, la documentation prévoit l’API Sessions et une cohérence séquentielle à l’intérieur d’une session ; cela ne doit pas être résumé en une garantie générale de cohérence forte mondiale. D1 n’expose pas le protocole Redis. Documentation D1, réplication en lecture
R2 : stocker des objets et des fichiers
R2 est un stockage objet : images, documents, exports et autres contenus identifiés par une clé. Cette utilisation du mot « clé » ne le transforme pas en cache Redis ni en service de coordination. Une application peut, par exemple, conserver un export dans R2 et ses métadonnées dans une base adaptée aux recherches. Architecture R2
Cache API et Queues : deux autres besoins distincts
La Cache API permet de travailler avec des réponses HTTP mises en cache. Son contenu est local au centre de données qui traite l’opération ; il ne faut pas le considérer comme un état global durable. Cache API
Queues sert à découpler la production et le traitement de messages. Sa livraison au moins une fois implique de concevoir des traitements capables de recevoir à nouveau un message sans reproduire un effet indésirable. Une file de messages ne remplace pas, à elle seule, un stockage de sessions ou un classement Redis. Garanties de livraison de Queues
Quatre situations concrètes pour choisir
Un site existant utilise Redis comme cache d’objets. Commencer par confirmer la compatibilité de son extension ou de son framework avec Valkey, puis mesurer les accès réels. Une migration de moteur peut être plus proportionnée qu’une réécriture vers une API KV. Vérifier le comportement lorsque le cache est vide : le serveur principal doit supporter sa reconstruction.
Une application distribuée sert une configuration peu changeante. Un KV distribué peut simplifier la diffusion si une ancienne version reste acceptable pendant la propagation. Prévoir des versions de configuration et un comportement de repli. Une règle de sécurité exigeant une prise d’effet immédiate mérite une analyse différente.
Plusieurs utilisateurs tentent de réserver la même ressource. Déterminer d’abord quel système fait autorité et garantit une décision atomique. Un cache peut accélérer l’affichage de la disponibilité, mais il ne devrait pas devenir par accident l’arbitre d’une vente unique lorsque sa cohérence ne permet pas cette garantie.
Une application produit des documents en arrière-plan. Une file peut distribuer le travail, un stockage objet conserver les fichiers et une base enregistrer leur état. Cette séparation est parfois plus lisible qu’un moteur unique auquel on confie toutes les responsabilités. Elle ajoute aussi des intégrations à surveiller : chaque service supplémentaire doit avoir une raison d’être.
Performance, persistance et disponibilité : éviter les raccourcis
« En mémoire » ne veut pas nécessairement dire « sans stockage durable ». Valkey propose des instantanés RDB et un journal AOF, avec des choix de configuration et des compromis. La présence de ces mécanismes ne prouve pas qu’une politique de sauvegarde et de restauration a été définie ou testée. Persistance Valkey
Une transaction Valkey regroupe des commandes sans intercalation d’autres clients pendant leur exécution, mais ne fournit pas de retour arrière automatique des commandes déjà exécutées. Le mot « transaction » ne doit donc pas être interprété comme une équivalence complète avec les comportements d’une base SQL. Transactions Valkey
La réplication ne constitue pas non plus une garantie universelle de zéro perte. La documentation précise que des écritures acquittées peuvent encore être perdues lors d’un basculement selon la configuration. Réplication Valkey
Enfin, une limite de mémoire et une politique d’éviction influencent les données que le moteur peut retirer ou les écritures qu’il peut refuser. Une politique convenant à un cache reconstructible peut être inadaptée à un état métier indispensable. Gestion de l’éviction
Pour comparer deux options, mesurer le temps de réponse de l’application, notamment les requêtes lentes, les erreurs, le taux de succès du cache, les évictions et la charge du système de référence. Ajouter les coûts réseau, les sauvegardes, les réplicas et le temps d’exploitation. Un prix d’instance ou une latence annoncée isolément ne décrit pas le coût réel d’un service utilisable.
Sécurité : préciser qui protège quoi
Un moteur de données ne devrait pas être exposé directement à Internet sans une architecture et des contrôles adaptés. La documentation Valkey prévoit notamment des restrictions réseau, des contrôles d’accès et TLS. Ces mécanismes doivent être configurés et vérifiés ; leur existence dans le produit ne signifie pas qu’ils sont actifs dans un environnement donné. Sécurité Valkey
Pour un service géré, préciser qui contrôle les comptes, les secrets de connexion, les permissions, les sauvegardes et les alertes. Vérifier aussi les lieux de traitement et les conditions du fournisseur lorsque les données sont soumises à des exigences de résidence. Un service accessible depuis plusieurs pays n’apporte pas, à lui seul, une garantie de stockage dans une région précise.
Une démarche de migration maîtrisée
- Inventorier les usages. Identifier les applications, versions, clients, commandes, scripts et fonctions qui dépendent du moteur. Distinguer cache reconstructible et données à préserver.
- Fixer les critères métier. Définir le retard acceptable, la durée d’interruption tolérée et la perte maximale admissible. Déterminer qui valide ces critères.
- Choisir une cible précise. Examiner la licence, la compatibilité, le réseau, la région, les limites et la répartition des responsabilités. Éviter une décision fondée uniquement sur une marque.
- Tester un environnement représentatif. Vérifier expiration, concurrence, reconnexions, erreurs et montée en charge, avec des données d’essai appropriées.
- Préparer la récupération. Tester la restauration lorsqu’elle est nécessaire et établir le traitement des nouvelles écritures pendant la bascule et un éventuel retour arrière.
- Basculer avec des critères observables. Contrôler les parcours utilisateurs et les données utiles, pas seulement la réponse d’un port réseau. Prévoir une décision d’arrêt si les critères ne sont pas atteints.
- Stabiliser et documenter. Comparer les mesures, vérifier les accès et les alertes, puis retirer l’ancien environnement seulement après validation et selon la conservation convenue.
Cette approche rejoint celle d’une évolution de base de données préparée autour des applications. Une migration réussie se juge au fonctionnement du service et à sa capacité de récupération, pas seulement à la présence d’un nouveau moteur.
Quelle décision pour votre entreprise ?
Valkey constitue une option à examiner pour conserver un écosystème proche de Redis OSS avec une licence permissive. Redis reste une option à évaluer selon sa version, ses fonctionnalités et sa licence. Les services cloud spécialisés permettent d’autres architectures, à condition d’accepter leurs API et leurs garanties propres.
Le point de départ devrait être votre application : ce qu’elle stocke, les opérations qu’elle exécute, les conséquences d’une donnée périmée et les compétences disponibles pour l’exploiter. Une petite entreprise, une agence qui gère plusieurs sites et une plateforme transactionnelle n’ont pas nécessairement besoin de la même combinaison.
Vous pouvez consulter notre approche des services cloud et d’infrastructure ou discuter de votre environnement avec Nuagerie. L’objectif est de définir une solution proportionnée et une transition vérifiable, avec les responsabilités et les limites clairement établies.