Valkey vs Redis en 2026 : comparatif et guide de migration

En mars 2024, Redis Ltd. a annoncé qu'à partir de Redis 7.4 le code serait publié sous double licence RSALv2 et SSPLv1, deux licences non approuvées par l'OSI. La réaction a été immédiate : la Linux Foundation a lancé Valkey avec le soutien d'AWS, Google Cloud, Oracle, Ericsson et Snap. Le fork est parti de Redis 7.2.4, sous licence BSD. En mai 2025, Redis 8 a ajouté l'AGPLv3, licence approuvée par l'OSI, comme option à côté des deux autres — un signal positif, mais l'AGPLv3 est un copyleft fort : qui modifie Redis et le met à disposition d'utilisateurs à travers un réseau doit publier le code source de ces modifications, ce qui pose des questions réelles aux hébergeurs revendeurs et aux éditeurs de logiciels commerciaux. Pendant ce temps, Fedora a remplacé Redis par Valkey dès Fedora 41, et Debian 13 comme Ubuntu 24.04 proposent un paquet valkey-server dans leurs dépôts officiels.

La question la plus fréquente avant une migration est celle du protocole. Valkey implémente à 100 % le Redis Serialization Protocol dans ses deux versions.

RESP2 (le protocole historique) est intégralement supporté. Toutes vos bibliothèques clientes existantes — ioredis, Predis, redis-py, Jedis, StackExchange.Redis — communiquent avec Valkey sans aucune modification de code ou de configuration. Le remplacement est transparent au niveau du socket.

RESP3 (introduit avec Redis 6.0) est également supporté par Valkey 9.1. Ce protocole apporte des types de réponse enrichis — maps, sets, doubles, booléens, attributs — qui permettent aux clients modernes de réduire les aller-retours de parsing. Les bibliothèques qui activent RESP3 par défaut (ioredis 6, redis-py 8) fonctionnent sans modification avec Valkey.

Un point à vérifier : si votre client négocie le protocole via la commande HELLO, Valkey répond de manière identique à Redis. La commande HELLO 3 active RESP3 sur les deux systèmes de la même façon. Vous pouvez le confirmer sur une instance Valkey existante avec valkey-cli HELLO 3.

Le format des fichiers de persistance est l'autre point critique d'une migration, et c'est là que votre version de départ compte. Valkey est compatible avec Redis OSS 7.2 et toutes les versions open source antérieures ; à partir de Redis 7.4, les fichiers de données ne le sont plus.

RDB (Redis Database Backup) : Valkey lit les fichiers RDB jusqu'à la version 11, celle de Redis 7.2. Un fichier dump.rdb produit par Redis 7.2 ou antérieur s'importe directement dans Valkey 9.1 en le plaçant dans le répertoire dir de Valkey avant le démarrage. Redis 7.4 et Redis 8 écrivent des RDB de version 12 et au-delà, que Valkey refuse par défaut ; l'option rdb-version-check relaxed tente un chargement au mieux, interrompu dès qu'une donnée inconnue apparaît. Depuis ces versions, passez par une migration clé par clé (MIGRATE ou un outil dédié) ou laissez le cache se reconstituer.

AOF (Append-Only File) : jusqu'à Redis 7.2, le format de journal AOF est le même que celui de Valkey. Si vous utilisez la persistance AOF ou le mode mixte (aof-use-rdb-preamble yes) sur ces versions, vos fichiers existants sont lus par Valkey sans modification. La commande BGSAVE et BGREWRITEAOF se comportent de la même façon.

Format de données en mémoire : les structures de données Valkey — strings, hashes, lists, sets, sorted sets, streams, HyperLogLog, bitmaps, geospatial — sont les mêmes que celles de Redis. Leurs encodages internes (listpack, skiplist, quicklist, intset) peuvent évoluer d'une version à l'autre sans effet côté client. Un client qui stocke un hash dans Redis le récupère intact depuis Valkey.

L'ensemble des commandes de Redis 7.2 est supporté par Valkey. Les catégories principales — strings, hashes, lists, sets, sorted sets, streams, pub/sub, transactions, scripting Lua, keyspace notifications, cluster — fonctionnent de façon identique.

Scripting Lua : Valkey supporte EVAL, EVALSHA et SCRIPT LOAD. Les scripts Lua écrits pour Redis s'exécutent sans modification sur Valkey. La bibliothèque cjson et les fonctions redis.call() sont disponibles, avec une nuance : Valkey a ajouté l'espace de noms server (server.call()) pour les nouveaux scripts, mais redis.call() reste fonctionnel pour la rétrocompatibilité.

Cluster : le protocole Gossip et les commandes de gestion de cluster (CLUSTER INFO, CLUSTER NODES, CLUSTER MEET, CLUSTER FAILOVER) sont identiques. Un nœud Valkey peut rejoindre comme réplique un cluster Redis 7.2 ou antérieur, ce qui permet la bascule — cependant, un cluster mixte Redis/Valkey n'est pas recommandé en production : les versions majeures peuvent introduire des différences de comportement sur les commandes internes. Migrer les nœuds un par un reste la voie sûre.

ACL (Access Control Lists) : le format des règles ACL est identique. Un fichier aclfile exporté depuis Redis (ACL SAVE) peut être rechargé dans Valkey. Les commandes ACL LIST, ACL SETUSER, ACL GETUSER fonctionnent de façon identique.

Keyspace notifications : la configuration notify-keyspace-events et les patterns de souscription (__keyevent@*__:set, etc.) sont identiques. Vos consumers pub/sub qui écoutent les événements keyspace n'ont pas à être modifiés.

Ce qui diffère : les modules Redis Stack — RedisJSON, RediSearch, RedisTimeSeries, RedisBloom —, intégrés à Redis 8, ne sont pas livrés avec Valkey. Valkey publie ses propres modules officiels : valkey-json (JSON.*), valkey-bloom (BF.*) et valkey-search (FT.*, recherche vectorielle), mais l'API n'est pas garantie identique et aucun module officiel ne remplace RedisTimeSeries. Si votre code appelle des commandes comme JSON.SET, FT.SEARCH ou TS.ADD, testez chacune avant de migrer.

La syntaxe de valkey.conf est identique à celle de redis.conf. Vous pouvez copier votre fichier de configuration existant sans réécriture. Quelques points méritent une vérification spécifique.

Chemins par défaut : Valkey utilise /etc/valkey/valkey.conf et /var/lib/valkey/ au lieu de /etc/redis/ et /var/lib/redis/. Si vous copiez votre configuration, mettez à jour les directives dir, logfile, pidfile et aclfile pour qu'elles pointent vers les chemins Valkey.

Nom du service systemd : le service s'appelle valkey-server sous Debian et Ubuntu (avec l'alias valkey) et valkey sous Fedora. Les commandes sont donc systemctl start valkey-server ou systemctl enable valkey.

TLS : Valkey supporte TLS sur les connexions clientes (tls-port, tls-cert-file, tls-key-file, tls-ca-cert-file) de façon identique à Redis 6+. Si vous avez activé TLS dans Redis, la même configuration fonctionne dans Valkey sans modification de vos clients.

maxmemory et éviction : les politiques d'éviction (allkeys-lru, volatile-lru, allkeys-lfu, noeviction, etc.) sont identiques. Votre politique actuelle se transfère directement.

Bind et protection-mode : Valkey démarre en mode protégé par défaut (comme Redis), qui refuse les connexions non-loopback si aucun mot de passe n'est défini. Votre configuration de bind et requirepass (ou ACL) se transpose directement.

C'est l'un des points forts de Valkey : aucune bibliothèque cliente ne nécessite de modification pour se connecter à Valkey. Le protocole étant identique, le client ne sait pas s'il parle à Redis ou à Valkey.

JavaScript / Node.js : ioredis, node-redis (redis npm), redis — tous fonctionnent. Changez uniquement l'hôte et le port dans votre configuration de connexion.

Python : redis-py (le paquet redis sur PyPI) et son client asynchrone redis.asyncio, qui remplace aioredis — compatibles. La connexion Redis(host='valkey-host', port=6379) fonctionne sans autre changement.

PHP : phpredis (extension C), Predis (pure PHP) — compatibles. Aucun changement de code.

Java : Jedis, Lettuce, Redisson — compatibles. Adaptez uniquement les paramètres de connexion.

.NET : StackExchange.Redis — compatible. Même chaîne de connexion, hôte et port mis à jour.

Go : go-redis, rueidis — compatibles.

Si vous utilisez une abstraction comme Laravel Cache (CACHE_STORE=redis), Django django-redis, Spring Data Redis ou Symfony Cache avec l'adaptateur Redis, ces couches d'abstraction se reconnectent à Valkey sans modification de code — seul le DSN de connexion change.

Valkey s'impose naturellement dans plusieurs contextes. Les hébergeurs et revendeurs sont les premiers concernés : l'AGPLv3 de Redis impose de publier les modifications apportées à Redis dès qu'il est offert à travers un réseau, et ses deux autres licences (RSALv2, SSPLv1) restreignent l'offre de Redis en service géré — des contraintes difficiles à concilier avec la plupart des offres commerciales. Les nouveaux projets qui n'ont pas besoin des modules de Redis 8 ont peu de raisons de partir sur Redis : Valkey est disponible dans les dépôts des distributions récentes et sa licence BSD est sans restriction. Les stacks RGPD et souveraineté bénéficient aussi de la gouvernance Linux Foundation, plus neutre qu'un éditeur privé. Enfin, si vous partez de Redis 7.2 ou antérieur et n'utilisez pas les modules Redis Stack (RedisJSON, RediSearch, RedisTimeSeries), la migration est transparente — toutes vos librairies et configurations existantes restent valides.

Valkey n'est qu'une pièce de votre stack de données. Si vous hébergez également une base relationnelle, consultez notre guide sur MariaDB sur VPS : configuration, performances et réplication. Pour le moteur de recherche full-text, Elasticsearch sur VPS couvre l'installation, le tuning mémoire et les index en production. Chaque composant mérite une configuration adaptée à votre charge — nos VPS Cloud vous donnent la maîtrise complète de votre environnement.