Redis et le prix de l’ambition

• Redis examine désormais même une grosse PR pour un type array en 2026, signe de sa transformation d’un simple serveur de structures de données en un produit couvrant de nombreux domaines
• À ses débuts, Redis, fidèle à l’idée de Remote Dictionary Server, s’est rapidement imposé dans la stack web grâce à un dictionnaire en mémoire rapide, un ensemble de commandes restreint et un protocole simple
• Au cours des dix dernières années, Redis s’est étendu avec Streams, JSON, la recherche, les graphes, les séries temporelles, Redis-Raft, les vector sets, etc., renforçant son orientation database
• Cette inflation fonctionnelle affaiblit les points forts historiques de Redis, à savoir la simplicité et la cohérence, tout en multipliant les intégrations inabouties dans des domaines qui exigent des outils spécialisés
• Valkey, plutôt que de courir après des fonctionnalités tape-à-l’œil, se concentre sur les performances multithread, l’efficacité mémoire et la fiabilité du cluster, en visant la base d’utilisateurs du Redis de 2011

---

L’identité perdue de Redis

• Redis est allé jusqu’à envisager en 2026 une grosse PR pour ajouter un type array, ce qui symbolise sa transformation d’un simple serveur de structures de données en un produit cherchant à couvrir de nombreux domaines
• La PR array type d’antirez part du constat que Hash, List et Stream ont chacun leurs points forts — accès arbitraire, append/trim, événements append-only — mais n’offrent pas à la fois un accès intermédiaire et une visibilité par plage comme un tableau
• Redis dispose déjà de fonctions utilisables comme des tableaux, comme les tableaux JSON, les séries temporelles ou les sorted-set, mais le simple fait de vouloir ajouter encore un nouveau type illustre bien cette logique d’expansion fonctionnelle
• Le problème central est l’affaiblissement de ce qui avait fait le succès initial de Redis : la simplicité, un protocole clair, des commandes restreintes et orthogonales, ainsi qu’une cohérence conceptuelle

Les changements de ces dix dernières années

• Licence et orientation de l’entreprise

  • Redis Inc a abandonné la licence BSD en 2024, avant de revenir à un schéma de triple licence dont AGPLv3 est la seule option reconnue par l’OSI
  • Grâce à l’AGPLv3, Redis Inc peut se dire open source, mais cette licence est de nature très différente de la BSD
  • L’entreprise soutenue par le capital-risque derrière Redis était à l’origine Garantia Data, un service d’hébergement cloud NoSQL ; après s’être recentrée sur l’hébergement Redis, elle a adopté un nom de la famille Redis et fait venir antirez pour gagner en légitimité
  • Quelques années plus tard, le transfert de la marque a posé les bases du changement de licence, et les anciens billets et commentaires liés au sujet ont aujourd’hui vieilli de manière assez prévisible

• Inflation fonctionnelle et positionnement produit

  • Redis a commencé avec un petit nombre de types de données utiles, mais a fini par intégrer des structures de données exotiques, des systèmes stateful complexes comme Streams et, selon les versions, des modules au caractère semi-propriétaire
  • En 2026, le positionnement de Redis sur sa landing page est devenu : “The Real-Time Context Engine for AI Apps”
  • On y voit côte à côte les boutons “Try Redis for Free” et “Get a Demo”, comme le montre aussi cette capture d’écran

• Orientation base de données web scale

  • Des fonctions comme Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash® montrent que Redis poursuit depuis longtemps l’objectif de devenir une “base de données web scale”

• Évolution du protocole et cache côté client

  • RESP3 rompt à bien des égards avec le modèle requête/réponse qui sous-tendait RESP2, et se rapproche de ce que Brooks décrivait comme les travers du “second système”
  • Redis était à l’origine largement utilisé comme cache, mais il en est arrivé au point d’avoir besoin d’un nouveau protocole pour prendre en charge le cache côté client

Pourquoi le Redis des débuts tombait juste

• Contexte de l’époque

  • Autour de 2011, des tendances comme NoSQL, “web scale”, Bigtable, Dynamo, Ruby on Rails, REST et JSON étaient très présentes chez les développeurs web
  • Redis correspondait parfaitement à cette ambiance et s’est retrouvé dans de nombreuses stacks presque du jour au lendemain
  • Fin 2011, Redis se présentait comme un advanced key-value store et un data structure server ; le mot “database” n’apparaissait pas

• Un dictionnaire distant meilleur que Memcached

  • memcached était une infrastructure indispensable qui tournait discrètement sur de nombreux serveurs web, utilisée non seulement pour le cache mais aussi pour des usages temporaires comme les verrous, les compteurs ou le rate limiting
  • Redis était alors perçu comme un outil proche de “memcached but way better”, et son nom, Remote Dictionary Server, mettait justement l’accent sur cette idée de dictionnaire rapide en mémoire
  • Redis proposait non seulement des blobs d’octets, mais aussi des structures bien choisies comme linked-list, hash-table, set et sorted-set, ce qui élargissait fortement la gamme des usages temporaires et pratiques

• Un protocole simple et suffisamment expressif

  • Le protocole réseau de Redis était assez simple pour être compris et implémenté en une heure, tout en restant assez puissant pour exprimer plusieurs types de données
  • Les bibliothèques clientes étaient simples et propres à implémenter, et le protocole lui-même donnait une impression de naturel
  • Le tutoriel write your own Redis pour créer soi-même un protocole Redis et un serveur simple reste un article populaire écrit il y a une dizaine d’années

• Monothread, orienté événements, en mémoire

  • La conception monothread de Redis garantissait l’atomicité de toutes les opérations, ce qui réduisait fortement la complexité et facilitait le raisonnement
  • Pour qu’un modèle monothread fonctionne, le serveur devait être implémenté en I/O non bloquantes, et les opérations sur les données devaient aussi être très rapides
  • Cette combinaison permettait à un seul thread de faire tourner un key/value store rapide capable de servir de nombreux clients

• Des structures de données adaptées aux applications web

  • Les chaînes et les expirations convenaient au cache, les listes aux files, et les hash aux données structurées
  • Des usages comme les verrous, les compteurs, le rate limiting, la liveness, la supervision ou les leaderboards pouvaient être construits facilement à partir des types intégrés

L’ambition de devenir une base de données

• L’adoption de Redis a progressé très vite et le projet a connu un grand succès, mais à un certain moment son ambition a basculé vers l’objectif de devenir une database
• Certaines fonctionnalités étaient réellement utiles ; par exemple, BZPOPMIN, ajouté dans Redis 5.0, a permis de faire un blocking pop sur des sorted-set utilisées comme priority queue, ce qui a renforcé son côté pratique
• À l’inverse, des fonctions comme les ACL paraissaient peu dans l’esprit de Redis, et l’on voyait de plus en plus une volonté de transformer Redis en solution universelle
• L’ajout de fonctionnalités dans Redis rejoint d’ailleurs les “dernières modes” dont les développeurs parlaient sur Hacker News ces dix dernières années
  • Puisque MongoDB stocke du JSON, Redis devrait lui aussi devenir une document database
  • Puisque ElasticSearch propose la recherche full-text, Redis devrait lui aussi devenir un search engine
  • Quand les graph databases ont gagné en visibilité, Redis a lui aussi voulu devenir une graph database, avant d’aboutir ensuite à la fin de vie de RedisGraph
  • Quand Kafka a attiré l’attention, Redis a voulu lui aussi devenir une event streaming platform
  • Quand ZooKeeper et les bases à forte cohérence sont devenus importants, Redis-Raft est arrivé, et l’analyse Jepsen d’Aphyr est souvent considérée comme quasi incontournable
  • Quand InfluxDB s’est imposé, Redis a lui aussi voulu devenir une time series database
  • Et pour ne pas rater la vague IA, il lui faut désormais aussi des fonctions liées à l’IA comme les vector sets

Le prix de l’expansion fonctionnelle

• Le premier problème est que Redis affaiblit lui-même ce qui en avait fait un outil essentiel dans la stack de tout le monde
  • Redis était simple, ses commandes étaient orthogonales et étroitement définies, son protocole était propre, et l’ensemble formait un outil conceptuellement cohérent
• Le deuxième problème est que les utilisateurs qui veulent sérieusement intégrer la recherche full-text, le traitement de flux d’événements, un key/value à forte cohérence, les séries temporelles ou le stockage vectoriel veulent des outils spécialisés, pas des modules à moitié aboutis héritant des limites de Redis
• La haute disponibilité de Redis est complexe, sa persistance implique des compromis subtils, et la lourdeur du protocole ainsi que la fragmentation des clients constituent aussi de vrais obstacles
• Redis n’est pas un outil destiné à remplacer Postgres, et des systèmes comme ElasticSearch ou RabbitMQ doivent continuer d’exister comme piliers spécialisés à part entière
• L’analyse de la première implémentation de Redis-Raft par Aphyr indique avoir trouvé 21 problèmes
  • une indisponibilité prolongée sur un cluster pourtant sain
  • 8 crashs
  • 3 stale reads
  • 1 aborted read
  • 5 bugs entraînant la perte de mises à jour pourtant validées
  • 1 boucle infinie
  • 2 problèmes capables d’envoyer aux clients des réponses logiquement corrompues
  • la première version testée, 1b3fbf6, a été jugée en pratique inutilisable
• Redis comme cache et serveur de structures de données n’est pas la même proposition que “Redis en tant qu’etcd” ou qu’un autre type de base spécialisée, et c’est précisément cet écart qui constitue le problème de fond

Le même schéma révélé par Disque

• En 2015, antirez a présenté Disque et a expliqué qu’il ne partait pas d’un cas d’usage réel, mais d’une conception en “astronaut mode”, inspirée à la fois par les gens qui utilisaient Redis comme file de messages et par l’existence d’autres systèmes de messagerie
• Un projet créé comme défi personnel ou exercice d’apprentissage, sans cas d’usage réel au départ, peut être excellent ; mais la capacité à résoudre ensuite durablement les problèmes difficiles de longue traîne qui apparaissent avec de vrais utilisateurs est une autre question
• La distribution de messages hautement disponible est un problème difficile à résoudre correctement, et quel que soit le côté du théorème CAP que l’on optimise, on n’échappe ni aux compromis ni aux problèmes ardus
• En 2015, il existait déjà de nombreux message brokers matures, et si les gens utilisaient Redis comme broker, c’était surtout parce qu’ils utilisaient déjà Redis et qu’il était suffisamment simple
• Ce qu’il fallait, ce n’était ni un nouveau message broker, ni un Redis transformé en broker plus complexe
• Disque est devenu de fait un abandonware presque immédiatement après son annonce, bien qu’il ait obtenu 8K stars sur GitHub
• Il a ensuite été réécrit comme module Redis, mais ce projet aussi est resté abandonné depuis 7 à 8 ans

Une autre direction illustrée par Valkey

• Les forces qui ont orienté Redis tiennent ensemble dans une même dynamique : l’ambition des développeurs de résoudre des problèmes complexes, l’ambition de devenir tout pour tout le monde, et l’ambition du propriétaire de Redis d’extraire un maximum de revenus avant d’être dépassé par AWS et GCP
• L’ambition en soi n’est pas le problème ; elle le devient lorsqu’elle fait perdre de vue les raisons du succès initial
• L’existence de Valkey et son adoption sont présentées comme le verdict final d’un marché plus large sur cette dynamique
• Plutôt que de courir après les fonctionnalités ou les puces d’un tableau comparatif, Valkey investit dans des travaux moins spectaculaires : performances multithread, efficacité mémoire, fiabilité du cluster et amélioration du débit
• Les benchmarks de performance de Valkey sont impressionnants, et le projet vise directement les 80 % d’utilisateurs de Redis pour qui les capacités du Redis de 2011 suffisent largement
• Dans l’univers de Valkey, la conclusion est qu’il n’y a pas besoin d’un nouveau type array

[GN⁺]

Avis sur Lobste.rs

• Pour quelqu’un qui a déjà fait grandir un projet open source à une échelle assez importante, fondé une entreprise, connu des centaines de millions de dollars de chiffre d’affaires, une IPO, puis une vente à plusieurs milliards, et qui a aussi procédé en chemin à un changement de licence s’éloignant de l’OSS, le positionnement de Redis comme « moteur de contexte en temps réel pour les applications d’IA » semble aller dans la bonne direction.
  Dans l’achat de logiciels, il y a les utilisateurs réels et les décideurs techniques (TDM) ; la landing page de Redis ressemble davantage à un site visant des TDM disposant du budget qu’à des développeurs utilisateurs. Beaucoup de TDM préfèrent des décisions qui ne leur vaudront pas un licenciement, dans l’esprit de « personne n’a jamais été viré pour avoir choisi IBM », et si Gartner ou McKinsey insistent sur la stratégie IA et la gestion du contexte, alors « Context Engine pour applications d’IA » devient une justification d’achat défendable.
  Chez HashiCorp aussi, il y a eu une tentative de séparer terraform.io pour les praticiens et hashicorp.com pour les TDM ; cela a fonctionné jusqu’à un certain point, mais avec des limites. C’est un problème difficile pour une entreprise OSS pilotée par les développeurs.
  Les boutons « utiliser Redis gratuitement » et « demander une démo » n’ont rien d’étrange non plus du point de vue d’un TDM. Les TDM ne veulent pas porter la responsabilité d’une décision technique et préfèrent souvent payer pour acheter un logiciel ; le gratuit est donc relégué au rang d’essai, tandis qu’un appel à l’action menant vers un humain est mis en avant.
  Les dirigeants de Redis Inc. semblent avoir conclu qu’il est plus important de séduire les TDM que les développeurs/opérateurs ; sans données internes, difficile de dire si c’est juste ou non, mais ce n’est probablement pas une stratégie adoptée sans intention.
  Le fait d’ajouter sans cesse des fonctionnalités s’explique aussi par le fait que le coût d’extension d’un outil existant est bien inférieur à celui de l’adoption d’un nouvel outil. Même sans motivation commerciale, les langages de programmation finissent souvent par devenir le plus petit dénominateur commun de toutes les fonctionnalités plutôt que de préserver une identité de base, et dans une entreprise commerciale, la logique de « land and expand » agit fortement. On décroche un premier contrat grâce à une fonctionnalité vitrine, puis on vend des fonctions annexes moyennes ; pour les achats, étendre un contrat existant est plus facile que d’en ouvrir un nouveau.
  L’idée selon laquelle « les clients sérieux voudront de vrais produits spécialisés pour la recherche, les event streams, les KV à forte cohérence, les séries temporelles ou les vector stores » est elle aussi très discutable. Rien qu’en regardant les données d’entreprises de logiciels cotées, on voit souvent des clients choisir des options moins bonnes pour des raisons non techniques.
  Il est aussi difficile d’affirmer que Valkey constitue le verdict final du marché. Valkey se porte bien mieux que la moyenne des forks (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), mais l’entreprise Redis semble aussi tenir le coup vue de l’extérieur. Si l’on regarde des sociétés comme ElasticSearch ou MongoDB, qui ont changé de licence et vu apparaître des forks sans subir de choc majeur sur leur valorisation publique, on peut aussi arriver à d’autres conclusions. Dans la bulle développeur, cela peut sembler différent, mais si le chiffre d’affaires est l’indicateur final en retard, on peut aussi se demander : « est-ce que cela comptait vraiment ? »
  Il ne s’agit pas de défendre les intérêts commerciaux, seulement de partager le point de vue de ce camp. Un peu comme, face aux mêmes produits agricoles, les questions et les objectifs d’un client qui fait ses courses et d’un agriculteur sont complètement différents.

  • Le « pourquoi » du point de vue commercial est bien expliqué, avec le contexte rappelant que Redis n’évolue pas dans le vide d’un logiciel pur, que la cible n’est pas les nerds de l’OSS, et que les décideurs n’ont pas les mêmes critères que les ingénieurs systèmes.
    Cela dit, cette logique donne l’impression de supposer que l’objectif de tout le monde est l’argent. Or l’ambition de gagner énormément d’argent avec Redis n’est qu’une ambition parmi d’autres, et à lire l’attitude d’antirez dans son billet, il ne donne pas l’impression d’avoir particulièrement couru après l’argent.
    On peut citer SQLite comme contre-exemple. Sans parler de revenus de plusieurs millions ou d’une vente à plusieurs milliards, le projet s’est contenté de fournir discrètement quelque chose de bien défini. SQLite n’a pas perdu la raison pour laquelle il est devenu la base de données embarquée la plus populaire, et côté grosses bases de données, on peut en dire autant de Postgres. On peut donc aussi tirer des contre-exemples de ce monde-là, tout autant que du monde de l’argent et des intérêts commerciaux.
    Pour Redis, la logique semble plutôt être : « on utilise déjà AWS/GCP, donc prenons leur équivalent de Redis », ce qui ressemble à un résultat naturel de l’expansion horizontale. Une voie encore plus à la IBM consiste à choisir un fournisseur cloud puis à utiliser son Redis ; aujourd’hui, cela signifie Valkey.
    Que les gens choisissent parfois de moins bonnes options n’est pas un sujet de débat mais un fait, et le fait que Redis se soit développé dans ce mode est justement un exemple de l’ambition et de la dérive que l’on voulait souligner.
  • J’ai travaillé chez Redis Labs, donc j’étais presque littéralement dans la position de l’avocat du diable côté développeur. En partant, je n’ai pas exercé mes options acquises, et comme je vis loin de la Silicon Valley, je peux parler sans trop craindre de brûler trop de ponts.
    À l’époque, redis.com était le site pour les TDM et redis.io celui pour les développeurs, mais après que Redis Labs a récupéré redis.io des mains d’antirez, ils l’ont tellement abîmé qu’il est devenu difficile d’y trouver ne serait-ce qu’un lien de téléchargement, et maintenant les deux URL renvoient vers des sites pour TDM. Encore aujourd’hui, il est difficile de trouver facilement un lien de téléchargement de Redis, au point que j’ai envie de dire aux gens d’aller le chercher eux-mêmes.
    Le problème central, c’est que Redis Labs a toujours très mal recruté sa direction marketing. Des CMO et VP arrivaient, brûlaient autant de capital sympathie que possible en peu de temps, puis partaient six mois plus tard pour « leur prochaine aventure ». Lorsqu’ils ont vu que le trafic de redis.io dépassait largement celui de redis.com, le fait d’avoir saboté redis.io dans l’espoir que les gens incapables de trouver le lien de téléchargement cliquent sur « try free » ressemble à un exemple typique d’obsession court-termiste du clic.
    La vente de fonctionnalités annexes aide aussi à se différencier des concurrents sur les cases à cocher. C’est particulièrement vrai quand on ne peut pas vraiment rivaliser sur le prix ; AWS pouvait vendre ElastiCache avec de fortes remises cloud groupées, et le pire concurrent restait Redis open source, gratuit.
    Valkey reçoit bien plus d’argent qu’un fork ordinaire. Par exemple, l’ancien responsable des relations développeurs de Redis Labs travaille maintenant sur Valkey chez AWS.
    Cela dit, je trouve regrettable l’idée que Valkey ne ferait que du « travail peu glamour ». Redis était déjà multithread depuis longtemps ; le plan de contrôle reste mono-thread, mais l’I/O est multithread, donc le travail de Valkey n’est pas aussi nouveau que l’auteur semble le penser.
    Valkey est très explicitement une manœuvre permettant à des entreprises cloud comme AWS de continuer à vendre Redis sans payer personne. Tous les autres arguments ne sont que des outils marketing destinés à convaincre qu’ils devraient pouvoir continuer à faire ce qu’ils veulent faire de toute façon ; s’ils jugent commercialement avantageux de casser la compatibilité avec Redis, ils le feront. Je miserais volontiers qu’il y a déjà eu un peu de cela des deux côtés, sans avoir suffisamment suivi le sujet.
    Si vous voulez un véritable fork de Redis qui fasse le travail peu glamour tout en essayant de préserver la simplicité, il y a redict.
    Malgré tout, je pense que le temps de Redis touche à sa fin. Dans l’étrange paysage commercial actuel, chaque fork boite d’une manière ou d’une autre. Même redict, malgré toutes ses vertus, ne semble pas vraiment animé par l’envie de pousser Redis vers l’avant comme à l’époque où antirez faisait avancer le projet originel en dictateur bienveillant. Cela ne veut pas dire qu’un logiciel « terminé » soit une mauvaise chose, mais je pense qu’il reste encore à Redis des territoires intéressants et inexplorés, et je doute que les forks commerciaux créent un tel écosystème. Bien sûr, il est aussi possible que je sous-estime la valeur des Arrays et des usages liés à l’IA, donc je reste à l’écoute.
    Avec le recul, il est presque surprenant que Redis Labs ait réussi à tout gâcher à ce point, et c’est tant mieux si assez de temps a passé pour que j’en sois moins en colère.
  • J’ai l’impression que les entreprises veulent prendre le plus possible sans payer. C’est bien pour cela que Redis, MongoDB et HashiCorp ont fini par changer de licence, non ?

• Au travail, on construit un système de file d’attente plus équitable avec des scripts Lua, et Redis me paraît vraiment étrange. Dans ma tête, le modèle a toujours été celui d’un « simple magasin clé-valeur », et voilà que j’apprends toutes sortes de fonctionnalités comme l’exécution de scripts Lua sous un verrou global.
  Pourtant, la documentation est sur un site web tout en paillettes, sans expliquer clairement les choses. Même les paramètres de configuration ne sont décrits que dans des exemples de configuration.
  Je sais que Redis fonctionne bien et tout le monde le dit, mais l’expérience d’apprentissage de ses fonctionnalités est assez désagréable. On a l’impression que quelqu’un a créé un très bon programme, puis a oublié la très bonne documentation qu’un bon programme devrait normalement avoir.
  C’est une plainte un peu étrange. Redis semble fonctionner extrêmement bien, et j’aime les documentations qui expliquent « tout », comme celle de Postgres.

  • Je me demande si la documentation d’un produit moins orienté TDM est plus facile à comprendre : https://valkey.io/topics/programmability/
    Beaucoup de projets open source savent aussi qu’ils sont faibles sur la documentation, donc dans cette expérience il n’y a probablement pas que la variable du patron à cheveux pointus.
  • Redis avait autrefois toutes sortes de documents, et heureusement Wayback Machine permet de réparer les dégâts causés par Redis Labs. Vous trouverez peut-être ce que vous cherchez ici : https://web.archive.org/web/20190725152042/…
    La documentation de redict a aussi l’air bonne : https://redict.io/docs/scripting/