Redis und der Preis des Ehrgeizes

• Redis prüft inzwischen sogar einen PR für einen array type im Jahr 2026 und hat sich damit von einem einfachen Datenstruktur-Server zu einem Produkt entwickelt, das viele Bereiche abdecken will
• Das frühe Redis etablierte sich als Remote Dictionary Server schnell im Web-Stack – mit einem schnellen In-Memory-Dictionary, einem schmalen Befehlssatz und einem einfachen Protokoll
• In den letzten zehn Jahren hat sich Redis mit Streams, JSON, Search, Graph, Time-Series, Redis-Raft, Vector Sets usw. stark erweitert und sich deutlich stärker in Richtung Datenbank bewegt
• Diese Funktionsausweitung schwächt die früheren Stärken von Redis – Einfachheit und Konsistenz – und vermehrt halb ausgereifte Integrationen in Bereiche, für die eigentlich spezialisierte Werkzeuge nötig sind
• Valkey konzentriert sich statt auf glänzende Feature-Jagd auf Multithread-Performance, Speichereffizienz und Cluster-Zuverlässigkeit und zielt damit auf die Redis-Nutzerschaft im Stil von 2011

---

Die verlorene Identität von Redis

• Redis ist inzwischen an einem Punkt angelangt, an dem 2026 ein großer PR zur Einführung eines array type geprüft wird. Das symbolisiert den Wandel von einem einfachen Datenstruktur-Server hin zu einem Produkt, das viele Bereiche umfassen will
• Der array type PR von antirez geht davon aus, dass Hash, List und Stream zwar jeweils Stärken bei wahlfreiem Zugriff, Append/Trim bzw. Append-only-Events haben, aber keinen gemeinsamen Typ bieten, der wie ein Array sowohl Zugriff in der Mitte als auch Sichtbarkeit über Bereiche hinweg ermöglicht
• Redis besitzt bereits array-artige Funktionen wie JSON-Arrays, Time-Series und Sorted Sets, doch schon die Richtung, erneut einen neuen Typ hinzufügen zu wollen, zeigt den Charakter dieser Funktionserweiterung deutlich
• Das Kernproblem ist, dass die Gründe für den ursprünglichen Erfolg von Redis – Einfachheit, ein klares Protokoll, ein schmaler und orthogonaler Befehlssatz sowie konzeptionelle Konsistenz – zunehmend schwächer werden

Die Veränderungen der letzten zehn Jahre

• Lizenz und Richtung des Unternehmens

  • Redis Inc stellte 2024 die BSD-Lizenz ein und zog sich danach auf ein Dreifach-Lizenzmodell zurück, in dem AGPLv3 die einzige OSI-Option ist
  • Dank AGPLv3 kann Redis Inc zwar weiterhin behaupten, Open Source zu sein, aber diese Lizenz ist vom Charakter her etwas völlig anderes als BSD
  • Das VC-finanzierte Unternehmen hinter Redis war ursprünglich Garantia Data, ein NoSQL-Cloud-Hosting-Service. Nach dem Wechsel zum Redis-Hosting wurde der Name auf die Redis-Familie umgestellt und antirez an Bord geholt, um Legitimität zu gewinnen
  • Der einige Jahre später erfolgte Übergang der Markenrechte legte die Grundlage für den späteren Lizenzwechsel, und frühere Beiträge und Kommentare dazu wirken heute auf vorhersehbare Weise veraltet

• Funktionsausweitung und Produktpositionierung

  • Redis begann mit einer kleinen Zahl nützlicher Datentypen, nahm mit der Zeit aber exotische Datenstrukturen, komplexe zustandsbehaftete Systeme wie Streams und je nach Version Module mit halb proprietärem Charakter auf
  • 2026 lautet die Positionierung auf der Redis-Startseite: “The Real-Time Context Engine for AI Apps”
  • Auf der Startseite stehen zugleich die Buttons “Try Redis for Free” und “Get a Demo”, wie auch im Screenshot zu sehen ist

• Ausrichtung auf eine Web-Scale-Datenbank

  • Funktionen wie Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex® und Redis-on-Flash® zeigen, dass Redis sich in Richtung einer „Web-Scale-Datenbank“ entwickelt hat

• Protokolländerungen und clientseitiges Caching

  • RESP3 bricht an vielen Stellen mit dem für RESP2 grundlegenden Request/Response-Modell und wird eher als Beispiel für das von Brooks beschriebene Scheitern des zweiten Systems bewertet
  • Redis wurde ursprünglich breit als Cache eingesetzt, braucht inzwischen aber sogar ein neues Protokoll, um clientseitiges Caching zu unterstützen

Warum das frühe Redis so gut passte

• Zeitlicher Kontext

  • Rund um 2011 waren unter Webentwicklern Strömungen wie NoSQL, „web scale“, Bigtable, Dynamo, Ruby on Rails, REST und JSON besonders stark
  • Redis passte perfekt in diese Atmosphäre und fand beinahe über Nacht Eingang in viele Stacks
  • Ende 2011 beschrieb sich Redis als advanced key-value store und data structure server; das Wort „database“ kam darin nicht vor

• Ein besseres Remote Dictionary als Memcached

  • memcached war essenzielle Infrastruktur, die unauffällig auf vielen Webservern lief, und wurde neben dem Caching oft auch provisorisch für Locks, Counter und Rate Limiting genutzt
  • Redis wurde damals im Sinne von „memcached but way better“ wahrgenommen, und schon der Name Remote Dictionary Server betonte den Charakter als schnelles In-Memory-Dictionary
  • Redis bot nicht nur Byte-Blobs, sondern auch gut gewählte Datenstrukturen wie Linked Lists, Hash Tables, Sets und Sorted Sets und weitete damit die pragmatischen Einsatzmöglichkeiten deutlich aus

• Ein einfaches und dennoch ausdrucksstarkes Protokoll

  • Das Redis-Wire-Protocol war so einfach, dass man es in einer Stunde verstehen und implementieren konnte, und zugleich stark genug, um mehrere Datentypen auszudrücken
  • Client-Bibliotheken ließen sich einfach und sauber implementieren, und auch das Protokoll selbst fühlte sich natürlich an
  • Das Tutorial write your own Redis zum Bau eines einfachen Redis-Servers und Protokolls ist bis heute ein populärer Beitrag von vor rund zehn Jahren

• Single-Threaded, eventbasiert, In-Memory

  • Das Single-Threaded-Design von Redis garantierte die Atomarität aller Operationen, reduzierte die Komplexität erheblich und erleichterte das Nachvollziehen des Verhaltens
  • Damit ein Single-Thread-Modell funktioniert, musste der Server mit non-blocking I/O umgesetzt sein, und auch die Datenoperationen mussten sehr schnell ablaufen
  • Diese Kombination machte einen schnellen Key/Value-Store möglich, der viele Clients in nur einem Thread bedienen konnte

• Datenstrukturen, die gut zu Webanwendungen passten

  • Strings mit Ablaufzeit passten zu Caches, Listen zu Queues und Hashes zu strukturierten Daten
  • Auch Anwendungsfälle wie Locks, Counter, Rate Limiting, Liveness, Monitoring und Leaderboards ließen sich allein mit den eingebauten Datentypen leicht umsetzen

Der Ehrgeiz, eine Datenbank zu werden

• Die Verbreitung von Redis nahm schnell zu und war ein großer Erfolg, doch ab einem gewissen Punkt verlagerte sich der Ehrgeiz des Projekts in Richtung Datenbank
• Manche Funktionen waren tatsächlich nützlich; so ermöglichte BZPOPMIN, das mit Redis 5.0 eingeführt wurde, beim Einsatz von Sorted Sets als Priority Queue ein Blocking Pop und erhöhte damit den praktischen Nutzen
• Andere Funktionen wie ACL wirkten dagegen untypisch für Redis, und insgesamt fiel der Drang auf, Redis zu allem für alle machen zu wollen
• Die Funktionsergänzungen von Redis spiegeln über die letzten zehn Jahre hinweg die „neuesten Trends“ wider, über die Entwickler auf Hacker News gesprochen haben
  • Wenn MongoDB JSON speichert, müsse Redis ebenfalls eine Document Database werden
  • Wenn ElasticSearch Full-Text Search bietet, müsse Redis ebenfalls eine Search Engine werden
  • Als Graph-Datenbanken Aufmerksamkeit bekamen, wollte Redis ebenfalls eine Graph Database werden, was später im RedisGraph EOL endete
  • Als Kafka in den Fokus rückte, wollte Redis ebenfalls eine Event-Streaming-Plattform werden
  • Als ZooKeeper und stark konsistente Datenbanken wichtiger wurden, erschien Redis-Raft, und die Jepsen-Analyse von Aphyr gilt beinahe als Pflichtlektüre
  • Als InfluxDB Aufmerksamkeit bekam, wollte Redis ebenfalls eine Time-Series-Datenbank werden
  • Um im AI-Trend nicht zurückzufallen, wurden auch AI-bezogene Funktionen wie Vector Sets nötig

Der Preis der Funktionserweiterung

• Das erste Problem ist, dass Redis damit genau die Eigenschaften selbst schwächt, die es zu einem unverzichtbaren Werkzeug in so vielen Stacks gemacht haben
  • Redis war einfach, die Befehle waren orthogonal und eng definiert, das Protokoll war sauber, und das Werkzeug war konzeptionell konsistent
• Das zweite Problem ist, dass Nutzer, die Full-Text Search, Event Stream Processing, stark konsistente Key/Value-Systeme, Time-Series oder Vector Storage ernsthaft integrieren wollen, keine halb ausgereiften Module mit den Beschränkungen von Redis suchen, sondern spezialisierte Werkzeuge
• Die Hochverfügbarkeit von Redis ist komplex, die Persistenz bringt feine Trade-offs mit sich, und auch Protokoll-Overhead sowie fragmentierte Clients sind reale Hürden
• Redis ist kein Werkzeug, das Postgres ersetzen soll, und Systeme wie ElasticSearch und RabbitMQ sollten jeweils eigenständige Grundpfeiler bleiben
• Aphyrs Analyse der frühen Redis-Raft-Implementierung berichtet von 21 Problemen
  • lange Phasen der Nichtverfügbarkeit in einem gesunden Cluster
  • 8 Abstürze
  • 3 Fälle von stale reads
  • 1 aborted read
  • 5 Bugs, die zum Verlust bestätigter Updates führten
  • 1 Endlosschleife
  • 2 Probleme, bei denen logisch beschädigte Antworten an Clients gesendet werden konnten
  • die erste getestete Version 1b3fbf6 wurde als praktisch unbenutzbar bewertet
• Redis als Cache und Datenstruktur-Server und ein Redis, das „Redis the etcd“ oder andere spezialisierte Datenbanken nachahmen will, sind grundlegend verschiedene Angebote – genau diese Lücke ist das Kernproblem

Disque als Beispiel für dasselbe Muster

• antirez stellte 2015 Disque vor und erklärte damals, dass es nicht aus realen Anwendungsfällen entstanden sei, sondern im „astronaut mode“ entworfen wurde – inspiriert von Menschen, die Redis wie eine Message Queue verwendeten, sowie von anderen Message Queues
• Projekte, die ohne realen Use Case als persönliche Herausforderung oder Lernaufgabe entstehen, können großartig sein; eine ganz andere Frage ist jedoch, ob man die lange Liste schwieriger Probleme lösen kann, die auftauchen, sobald die Nutzerzahl wächst
• Hochverfügbare Nachrichtenübermittlung ist ein schwer lösbares Problem, und unabhängig davon, welche Seite des CAP-Theorems optimiert wird, lassen sich Trade-offs und schwierige Probleme nicht vermeiden
• 2015 gab es bereits viele ausgereifte Message Broker, und der Grund, warum Menschen Redis als Message Broker nutzten, war, dass sie Redis ohnehin schon einsetzten und es hinreichend einfach war
• Was gebraucht wurde, war weder ein neuer Message Broker noch ein Redis, das zu einem noch komplexeren Message Broker wird
• Disque war kurz nach seiner Vorstellung faktisch abandonware und wurde trotz 8K Stars auf GitHub liegen gelassen
• Später wurde es erneut als Redis-Modul umgesetzt, doch auch dieses Projekt ist seit 7 bis 8 Jahren praktisch aufgegeben

Valkey zeigt eine andere Richtung

• Die Kräfte, die den Kurs von Redis bestimmt haben, bündeln sich in dem Ehrgeiz von Entwicklern, komplexe Probleme lösen zu wollen, in dem Ehrgeiz, alles für alle zu sein, und in dem Ehrgeiz der Eigentümer von Redis, den maximalen Ertrag herauszuholen, bevor sie gegen AWS und GCP zurückfallen
• Ehrgeiz an sich ist nicht das Problem; problematisch wird er, wenn dadurch verloren geht, warum ein Produkt überhaupt erfolgreich war
• Die Existenz und Verbreitung von Valkey wird als endgültiges Urteil eines breiteren Marktes über diese Dynamik dargestellt
• Statt Features hinterherzulaufen oder Bullet Points in Vergleichstabellen, investiert Valkey in weniger glanzvolle Arbeit wie Multithread-Performance, Speichereffizienz, Cluster-Zuverlässigkeit und Durchsatzverbesserungen
• Die Performance-Benchmarks von Valkey sind beeindruckend und zielen direkt auf die 80 % der Redis-Nutzer, für die das Redis von 2011 funktional bereits ausreicht
• In der Welt von Valkey lautet die Schlussfolgerung, dass kein neuer array type nötig ist

[GN⁺]

Lobste.rs-Kommentare

• Wenn man schon einmal Open Source ziemlich groß skaliert, eine Firma gegründet, Hunderte Millionen Dollar Umsatz sowie einen IPO und einen Verkauf in Milliardenhöhe erlebt und dabei auch schon einen Lizenzwechsel weg von OSS durchgeführt hat, dann wirkt die Positionierung von Redis als „Realtime Context Engine für AI-Apps“ von der Stoßrichtung her plausibel.
  Beim Softwarekauf gibt es tatsächliche Nutzer und technische Entscheidungsträger (TDMs), und die Redis-Landingpage wirkt eher wie eine Website für TDMs mit Budgetverantwortung als für tatsächliche Entwickler. Viele TDMs bevorzugen Entscheidungen, für die sie nicht gefeuert werden, nach dem Motto „Niemand wurde je gefeuert, weil er IBM gewählt hat“, und wenn Gartner oder McKinsey AI-Strategie und Context-Management betonen, wird eine „Context Engine für AI-Apps“ zu einer gut verteidigbaren Kaufbegründung.
  Auch bei HashiCorp versuchte man, terraform.io für Praktiker und hashicorp.com für TDMs zu trennen; das funktionierte bis zu einem gewissen Grad, hatte aber Grenzen. Für entwicklergetriebene OSS-Firmen ist das ein schwieriges Problem.
  Auch die Buttons „Use Redis for free“ und „Get a demo“ wirken aus TDM-Sicht nicht seltsam. TDMs wollen ungern Verantwortung für technische Entscheidungen tragen und möchten oft lieber Geld ausgeben und Software kaufen; deshalb wird „kostenlos“ eher wie eine Testversion heruntergestuft und der Call-to-Action, der zu einem Gespräch mit Menschen führt, prominent platziert.
  Das Management von Redis Inc. scheint zu dem Schluss gekommen zu sein, dass es wichtiger ist, TDMs anzusprechen als Entwickler/Operatoren; ohne interne Daten lässt sich schwer sagen, ob das richtig oder falsch ist, aber es dürfte keine strategiearme Entscheidung gewesen sein.
  Dass ständig neue Funktionen angehängt werden, liegt auch daran, dass die Kosten für die Erweiterung eines bestehenden Tools viel niedriger sind als die Einführung eines neuen. Selbst ohne kommerziellen Anreiz werden Programmiersprachen oft eher zum kleinsten gemeinsamen Nenner aller Funktionen, statt ihre Kernidentität zu bewahren, und in kommerziellen Firmen wirkt „land and expand“ besonders stark. Hat man den ersten Vertrag über eine Leitfunktion gewonnen, kann man zusätzlich mittelmäßige Zusatzfunktionen verkaufen, weil die Beschaffungsabteilung eine Erweiterung bestehender Verträge leichter durchwinkt als einen neuen Vertrag.
  Auch die Behauptung, „ernsthafte Kunden werden für Suche, Event Streams, stark konsistente KV-Stores, Zeitreihen und Vektor-Storage echte Spezialprodukte wollen“, ist sehr umstritten. Schon Daten von Public-Software-Unternehmen zeigen, dass Kunden aus nichttechnischen Gründen häufig schlechtere Optionen wählen.
  Auch dass Valkey das endgültige Urteil des Marktes sei, lässt sich nicht so eindeutig sagen. Valkey schlägt sich zwar viel besser als ein durchschnittlicher Fork (https://redmonk.com/sogrady/2026/04/06/valkey-at-two/), aber auch die Redis-Firma scheint sich von außen betrachtet gut zu halten. Schaut man auf Unternehmen wie ElasticSearch oder MongoDB, die ihre Lizenz geändert haben und bei denen Forks entstanden sind, ohne dass ihre Bewertung am öffentlichen Markt massiv gelitten hätte, sind auch andere Schlussfolgerungen möglich. In der Entwicklerblase mag das anders aussehen, aber wenn Umsatz der letztlich nachlaufende Indikator ist, kann man auch fragen: „War das wirklich so wichtig?“
  Das soll keine Verteidigung kommerzieller Interessen sein, sondern nur die Perspektive von dieser Seite schildern. Es ist ein bisschen so, als würden Käufer auf dem Wochenmarkt und Bauern auf dieselben Agrarprodukte schauen, aber völlig andere Fragen und Ziele haben.

  • Das „Warum“ aus kommerzieller Sicht wurde gut erklärt, und es kommt der Kontext dazu, dass Redis nicht in einem reinen Software-Vakuum existiert, OSS-Nerds nicht die Zielgruppe sind und Entscheidungsträger andere Maßstäbe haben als Systemingenieure.
    Allerdings wirkt diese Logik so, als setze sie voraus, dass das Ziel aller Geld sei. Der Ehrgeiz, mit Redis enorm viel Geld zu verdienen, ist aber nur eine bestimmte Form von Ehrgeiz, und nach dem Ton von antirez im Artikel liest er sich nicht wie jemand, dem Geld besonders wichtig war.
    Als Gegenbeispiel gibt es SQLite. Dort geht es nicht um Hunderte Millionen Umsatz oder einen Verkauf für zig Milliarden, sondern darum, still und konzentriert etwas klar Definiertes bereitzustellen. SQLite hat nicht verloren, warum es die beliebteste eingebettete Datenbank geworden ist, und bei größeren Datenbanken gilt Ähnliches für Postgres. Man kann aus dieser Welt genauso Gegenbeispiele ziehen wie aus der Welt von Geld und kommerziellen Interessen.
    Bei Redis scheint „Wir nutzen ohnehin schon AWS/GCP, also nehmen wir deren Redis-ähnliches Angebot“ die natürliche Folge horizontaler Expansion zu sein. Der noch IBM-artigere Weg ist, zuerst den Cloud-Anbieter zu wählen und dann dessen Redis zu nutzen — und heute ist das eben Valkey.
    Dass Menschen schlechtere Optionen wählen, ist keine Streitfrage, sondern eine Tatsache, und dass Redis in genau diesen Modus hinein skaliert wurde, ist eines der Beispiele für den Ehrgeiz und das Abdriften, das eigentlich hervorgehoben werden sollte.
  • Ich habe bei Redis Labs gearbeitet und war damit fast wortwörtlich in der Position des Devil’s Developer Advocate. Als ich ging, habe ich meine gevesteten Optionen nicht ausgeübt, und ich lebe weit weg vom Silicon Valley, sodass ich ohne große Sorge sprechen kann, zu viele Brücken abzubrennen.
    Früher war redis.com die TDM-Seite und redis.io die Entwicklerseite, aber nachdem Redis Labs das vorher antirez gehörende redis.io übernommen hatte, haben sie es so kaputtgemacht, dass selbst der Download-Link kaum noch zu finden war, und inzwischen leiten beide URLs auf TDM-Seiten. Auch heute ist der Redis-Download-Link nicht leicht zu finden; ich würde fast sagen: Such ihn selbst.
    Das Kernproblem ist, dass Redis Labs schon immer katastrophale Marketing-Führungskräfte eingestellt hat. CMO- und VP-Leute kamen, verbrannten in kurzer Zeit so viel Goodwill wie möglich und zogen sechs Monate später weiter zum „nächsten Abenteuer“. Als man sah, dass redis.io viel mehr Traffic hatte als redis.com, wirkte die Zerstörung von redis.io in der Hoffnung, dass Leute, die den Download-Link nicht finden, stattdessen auf „try free“ klicken, wie ein typischer Fall kurzfristiger Klickgier.
    Das Verkaufen von Zusatzfunktionen hilft auch dabei, sich in Checklisten gegenüber Wettbewerbern zu differenzieren. Das gilt besonders, wenn Preiswettbewerb schwierig ist; AWS konnte starke Cloud-Rabatte an ElastiCache koppeln, und der schlimmste Konkurrent war das kostenlose Open-Source-Redis.
    In Valkey fließt viel mehr Geld als in einen gewöhnlichen Fork. Der frühere Leiter der Developer Relations von Redis Labs arbeitet zum Beispiel jetzt bei AWS an Valkey.
    Etwas schade ist allerdings die Einschätzung, Valkey mache nur „unspektakuläre Arbeit“. Redis war schon seit Langem multithreaded; die Control Plane ist zwar noch single-threaded, aber I/O ist multithreaded, daher ist die Arbeit an Valkey nicht so neuartig, wie der Autor offenbar annimmt.
    Valkey ist ganz offen eine Operation, mit der Cloud-Firmen wie AWS Redis weiterverkaufen können, ohne irgendjemandem Geld zu zahlen. Alle anderen Begründungen sind nur Marketinginstrumente, um die Leute von etwas zu überzeugen, das sie ohnehin weiter tun wollen, und wenn sie zu dem Schluss kämen, dass es kommerziell vorteilhaft wäre, die Kompatibilität zu Redis zu brechen, würden sie das tun. Man kann wohl einigermaßen darauf wetten, dass es auf beiden Seiten schon in Ansätzen passiert ist, aber ich habe es nicht genau genug verfolgt.
    Wenn man einen echten Redis-Fork will, der unspektakuläre Arbeit macht und zugleich die Einfachheit bewahren will, dann gibt es redict.
    Trotzdem glaube ich, dass die Zeit von Redis zu Ende geht. In der heutigen seltsamen kommerziellen Landschaft hinkt jeder der Forks auf die eine oder andere Weise. Selbst dem tugendhaftesten redict fehlt echtes Interesse daran, Redis auf die gleiche Weise voranzutreiben wie damals, als antirez das Originalprojekt quasi diktatorisch geführt hat. Das heißt nicht, dass es schlecht wäre, wenn Software „fertig“ ist, aber ich glaube, dass es bei Redis noch unentdeckte spannende Bereiche gibt, und ich bezweifle, dass die kommerziellen Forks dafür ein solches Ökosystem schaffen werden. Natürlich unterschätze ich vielleicht den Wert von Arrays und AI-bezogenen Anwendungen, also halte ich mir bewusst die Ohren offen.
    Rückblickend ist es fast erstaunlich, wie gründlich Redis Labs das alles vermasselt hat, und immerhin ist inzwischen genug Zeit vergangen, dass ich weniger wütend darüber bin.
  • Vielleicht geht es Unternehmen einfach darum, möglichst viel mitzunehmen, ohne zu bezahlen. Deshalb haben Redis, MongoDB und HashiCorp am Ende wohl auch ihre Lizenzen geändert.

• In der Firma bauen wir gerade mit Lua-Skripten ein faireres Job-Queue-System, und Redis fühlt sich dabei sehr seltsam an. In meinem Kopf war es immer nur ein „einfacher Key-Value-Store“, und nun lerne ich lauter Funktionen kennen, etwa dass Lua-Skripte unter einem globalen Lock ausgeführt werden.
  Die Dokumentation liegt allerdings auf einer glitzernden Website und erklärt solche Dinge nicht klar. Konfigurationswerte werden teils nur innerhalb von Konfigurationsbeispielen erläutert.
  Ich weiß, dass Redis gut funktioniert, und das sagt auch jeder, aber das Lernen der Redis-Funktionen ist eine ziemlich unangenehme Erfahrung. Es fühlt sich an, als hätte jemand ein wirklich gutes Programm gebaut und dann die großartige Dokumentation vergessen, die ein gutes Programm normalerweise haben sollte.
  Ist vielleicht eine seltsame Beschwerde. Redis scheint extrem gut zu funktionieren, und ich mag Dokumentation, die wie die von Postgres wirklich „alles“ erklärt.

  • Ich frage mich, ob die Dokumentation eines weniger TDM-orientierten Produkts leichter verständlich ist: https://valkey.io/topics/programmability/
    Viele Open-Source-Projekte wissen allerdings auch sehr gut, dass ihre Dokumentation schwach ist, daher scheint dieses Experiment nicht nur die Variable „spitzhaariger Chef“ zu haben.
  • Früher hatte Redis alle möglichen Dokumente, und zum Glück kann man mit der Wayback Machine einen Teil des Schadens rückgängig machen, den Redis Labs angerichtet hat. Vielleicht findest du hier, was du suchst: https://web.archive.org/web/20190725152042/…
    Auch redict scheint gute Dokumentation zu haben: https://redict.io/docs/scripting/