Valkey: den Open-Source-Fork nach Redis' Lizenzänderung einordnen

1. Die Lizenzänderung im März 2024: von BSD zu SSPL und RSAL

Redis stand seit seiner Entstehung 2009 unter der dreiklausel BSD-Lizenz, einer der freizügigsten Open-Source-Lizenzen überhaupt, die auch die kommerzielle Nutzung und das Anbieten als gehosteten Dienst ohne Einschränkung erlaubte. Im März 2024 kündigte Redis Ltd an, ab Redis 7.4 auf ein duales Lizenzmodell umzustellen, bestehend aus der Server Side Public License und der neu geschaffenen Redis Source Available License.

Beide Lizenzen erlauben weiterhin das Lesen und Verändern des Quellcodes, schränken aber das Anbieten von Redis als verwalteten Cloud-Dienst durch Dritte deutlich ein, sofern diese nicht selbst substanzielle eigene Beiträge zum Projekt leisten. Diese Einschränkung richtete sich vor allem gegen große Cloud-Anbieter, die Redis als Managed-Service verkauften, ohne selbst signifikant zum Kernprojekt beizutragen, traf in der Wahrnehmung vieler Entwickler aber auch den Geist eines offenen Projekts.

2. Warum die Linux Foundation Valkey als eigenständigen Fork gründete

Wenige Tage nach der Ankündigung formierte sich unter Beteiligung von AWS, Google Cloud, Oracle, Ericsson und weiteren Unternehmen ein neues Projekt namens Valkey, das unter das Dach der Linux Foundation gestellt wurde. Die Linux Foundation bietet als neutrale Governance-Instanz eine Struktur, in der mehrere konkurrierende Unternehmen gemeinsam an einem Projekt arbeiten können, ohne dass eine einzelne Firma die Lizenzbedingungen künftig einseitig ändern kann, wie es bei Redis Ltd der Fall war.

Als Startpunkt diente der letzte BSD-lizenzierte Codestand von Redis, konkret Version 7.2.4, auf dessen Basis Valkey seither eigenständig weiterentwickelt wird. Innerhalb weniger Monate übernahmen mehrere Linux-Distributionen, darunter Debian und Amazon Linux, sowie Cloud-Anbieter Valkey als Ersatz für Redis in ihren jeweiligen Paketquellen, was dem Fork schnell eine breite praktische Verankerung verschaffte.

3. Technischer Ausgangspunkt und Governance-Modell von Valkey

Valkey wird durch ein technisches Steuerungskomitee geleitet, das aus Vertretern mehrerer beteiligter Unternehmen besteht und Entscheidungen über die Roadmap, größere Architekturänderungen und Release-Zyklen trifft. Dieses Modell unterscheidet sich bewusst von der vorherigen Struktur bei Redis, in der eine einzelne Firma die letztgültige Entscheidungsgewalt über Lizenz und Richtung hatte, und soll verhindern, dass ein ähnlicher Lizenzwechsel künftig erneut ohne Konsens der Community erfolgt.

Für Entwickler, die zu Valkey beitragen, gilt weiterhin ein offener Contribution-Prozess über GitHub mit öffentlich einsehbaren Diskussionen, ähnlich wie es vor der Lizenzänderung bei Redis üblich war. Wichtige Kernentwickler des ursprünglichen Redis-Projekts sind zu Valkey gewechselt, was dem Fork zusätzlich zur institutionellen Unterstützung auch tiefes technisches Wissen über die bestehende Codebasis sichert.

4. Aktueller Funktions- und Kompatibilitätsstand zu Redis

Da Valkey vom selben Codestand ausgeht, ist die Kompatibilität zu Redis auf Protokoll- und Befehlsebene zum Startzeitpunkt praktisch vollständig gewesen. Seither haben beide Projekte unabhängig voneinander neue Funktionen entwickelt: Valkey hat unter anderem eine überarbeitete Multi-Threading-Architektur für die I/O-Verarbeitung sowie ein natives Hash-Field-Expire-Feature vorangetrieben, während Redis Ltd eigene neue Funktionen wie erweiterte Vektorsuche-Fähigkeiten in den proprietäreren Redis-Versionen ausbaut.

Für die überwiegende Mehrheit der Standard-Anwendungsfälle, insbesondere Caching, Session-Speicherung und einfache Datenstrukturoperationen, bleibt die Kompatibilität zwischen beiden Projekten hoch, da beide dasselbe RESP-Protokoll implementieren und den Großteil der klassischen Befehle wie GET, SET, HSET oder EXPIRE identisch unterstützen. Bei sehr neuen, nach dem Fork-Zeitpunkt eingeführten Funktionen eines der beiden Projekte lohnt sich jedoch eine gezielte Prüfung vor dem Einsatz.

5. Praktische Kompatibilität: Clients, RDB- und AOF-Format, RESP-Protokoll

Für Anwendungsentwickler ist entscheidend, dass gängige Redis-Client-Bibliotheken wie predis oder phpredis im PHP-Umfeld ohne Änderung auch gegen Valkey funktionieren, da diese Bibliotheken gegen das RESP-Protokoll und nicht gegen eine bestimmte Server-Implementierung programmiert sind. Auch das RDB-Snapshot-Format und das AOF-Persistenzformat blieben zum Startzeitpunkt identisch, wodurch sich bestehende Datenbestände ohne Konvertierung von Redis nach Valkey übernehmen ließen.

Wichtig zu prüfen bleibt die genutzte Redis-Version im Vergleich zur Valkey-Version, da sich die Formate mit fortschreitender, unabhängiger Weiterentwicklung theoretisch auseinanderentwickeln können. Für ein Magento-Setup, das Redis primär für Full-Page-Cache, Konfigurationscache und Sessions nutzt, betrifft dies in der Praxis kaum kritische Funktionen, da Magento selbst über Standard-Redis-Adapter kommuniziert und keine proprietären Redis-Erweiterungen voraussetzt.

# Aktuelle Redis-Version im laufenden Betrieb prüfen
redis-cli INFO server | grep redis_version

# Valkey meldet sich über dieselbe INFO-Struktur, zusätzlich mit
# einem eigenen Feld zur Unterscheidung
redis-cli INFO server | grep -E "redis_version|valkey_version"

# RDB-Datei vor der Migration sichern
redis-cli SAVE
cp /var/lib/redis/dump.rdb /backup/dump-vor-valkey-migration.rdb

6. Performance-Unterschiede in der Praxis: Valkeys überarbeitetes I/O-Threading

Der sichtbarste technische Unterschied zwischen beiden Projekten liegt in der Weiterentwicklung des I/O-Threading-Modells. Während Redis I/O-Threads bislang primär für das reine Lesen und Schreiben von Netzwerkdaten nutzt, während die eigentliche Befehlsverarbeitung an einen einzigen Hauptthread gebunden bleibt, hat das Valkey-Team dieses Modell überarbeitet, um mehr Arbeit tatsächlich parallel über mehrere Threads verteilen zu können, ohne die von Anwendungen erwartete Atomarität einzelner Befehle aufzugeben.

In veröffentlichten Benchmarks der Valkey-Maintainer zeigt sich dadurch bei Workloads mit vielen gleichzeitigen Verbindungen ein spürbar höherer Durchsatz gegenüber vergleichbar konfiguriertem Redis, insbesondere auf Maschinen mit acht oder mehr Kernen. Für Magento-Betreiber mit sehr traffic-starken Shops kann dieser Unterschied relevant werden, sollte aber wie bei jeder Herstellerangabe durch einen eigenen Lasttest mit dem tatsächlichen Zugriffsmuster der Anwendung bestätigt werden, bevor er als Migrationsgrund dient.

7. Distro-Support: Debian, Amazon Linux und Cloud-Anbieter wechseln zu Valkey

Ein bedeutsames Signal für die praktische Relevanz von Valkey ist, dass mehrere große Linux-Distributionen, darunter Debian ab einer bestimmten Version, das redis-server-Paket durch Valkey ersetzt oder Valkey als eigenständiges, gleichwertiges Paket aufgenommen haben. Amazon Linux und mehrere Cloud-Anbieter haben ihre Managed-Cache-Dienste ebenfalls auf Valkey als Standard-Engine umgestellt, teilweise mit einer parallelen, kostenpflichtigen Option für lizenziertes Redis.

Für Betreiber bedeutet das konkret, dass ein einfaches apt install redis-server auf neueren Debian-Systemen inzwischen faktisch Valkey installiert, auch wenn die Kompatibilitätsschicht dies für die meisten Anwendungen transparent hält. Wer explizit weiterhin lizenziertes Redis Ltd-Redis benötigt, muss die entsprechenden Repositories mittlerweile bewusst und separat einbinden.

8. Lizenzrisiko-Bewertung für Magento-Betreiber: Self-hosted versus Managed

Für einen Magento-Shop, der Redis lediglich als Caching- und Session-Backend im eigenen Betrieb einsetzt, ohne Redis selbst als Managed-Service an Dritte weiterzuverkaufen, greifen die Einschränkungen der SSPL und RSAL in der Praxis kaum, da die Lizenz vor allem das Anbieten als konkurrierender Cloud-Dienst betrifft. Dennoch führt die Unsicherheit über künftige Lizenzentwicklungen bei vielen Betreibern zu einer grundsätzlichen Präferenz für Projekte mit klar dauerhaft freizügiger Lizenz.

Wer Redis über einen Managed-Service eines Cloud-Anbieters bezieht, muss sich um diese Frage ohnehin kaum kümmern, da der Anbieter die Lizenzbedingungen im Hintergrund klärt. Für Betreiber, die Wert auf maximale Zukunftssicherheit ihrer Open-Source-Abhängigkeiten legen, bietet die Governance-Struktur der Linux Foundation hinter Valkey eine strukturell verlässlichere Grundlage als ein einzelnes, kommerziell getriebenes Unternehmen.

9. Praktischer Migrationspfad: Schritt für Schritt von Redis zu Valkey

Ein Wechsel von Redis zu Valkey lässt sich in der Praxis meist ohne Anwendungsänderung durchführen, da die Konfigurationsdatei, das RESP-Protokoll und die Standardbefehle identisch bleiben. Empfehlenswert ist zunächst ein Test in einer Staging-Umgebung, in der Valkey als Ersatz für die bestehende Redis-Instanz installiert wird, während die Magento-Konfiguration für Cache- und Session-Backend unverändert bleibt, da beide Systeme dieselben Verbindungsparameter erwarten.

Für den produktiven Wechsel bietet sich ein Vorgehen über Replikation an: Valkey kann als Replika einer bestehenden Redis-Primärinstanz angebunden werden, den vollständigen Datenbestand synchron übernehmen und anschließend im Rahmen eines kontrollierten Wartungsfensters zur neuen Primärinstanz befördert werden. Dieses Vorgehen minimiert die Ausfallzeit und erlaubt einen schnellen Rollback, falls unerwartete Kompatibilitätsprobleme auftreten sollten.

10. Zusammenfassung

11. FAQ: Valkey als Redis-Fork: Das Wichtigste auf einen Blick