Redis oder Valkey: BSD-Lizenz trifft auf Redis’ Dreifachmodell

Für Cache- und Queue-Lasten mit üblichen Schlüssel-Wert-Befehlen ist Valkey oft die naheliegende Wahl, wenn eine freizügige Lizenz wichtig ist. Das Valkey-Projekt beschreibt seine BSD-lizenzierte Datenbank auch als Primärdatenbank und wird von der Linux Foundation getragen. Bei dauerhaft gespeicherten Daten müssen allerdings Wiederherstellung und Verfügbarkeit stärker ins Gewicht fallen als bei einem neu befüllbaren Cache.

Redis 8 ist besonders interessant, wenn Suche, JSON, Zeitreihen oder probabilistische Datenstrukturen bereits zur Anwendung gehören. Diese Funktionen sind in Redis Open Source integriert; Redis’ Funktionsvergleich führt für Valkey teils Module als mögliche Ergänzung auf. Die Entscheidung hängt deshalb zugleich von Lizenzpflichten, tatsächlich genutzten Befehlen und der Version eines vorhandenen Datenbestands ab.

Welche Lizenzfolgen hat die Wahl?

Für einen Anbieter gemanagter Datenbankdienste ist der Lizenzunterschied besonders folgenreich. Valkeys BSD-3-Clause-Lizenz erlaubt Nutzung, Änderung und Weitergabe mit vergleichsweise wenigen Bedingungen; bei einer Weitergabe müssen unter anderem Lizenz- und Urheberrechtshinweise erhalten bleiben. Das vereinfacht die rechtliche Einordnung, ersetzt aber keine Prüfung der übrigen Komponenten eines Dienstes.

Die Redis-Lizenzübersicht nennt für Redis Open Source ab Version 8 drei wählbare Optionen: RSALv2, SSPLv1 und AGPLv3. RSALv2 untersagt insbesondere, die Software Dritten als konkurrierenden gemanagten Dienst bereitzustellen. SSPLv1 knüpft an ein solches Dienstangebot weitreichende Pflichten zur Offenlegung des Quellcodes einschließlich der Verwaltungsebene. AGPLv3 ist eine anerkannte Open-Source-Lizenz mit Copyleft-Pflichten; bei Änderungen und Bereitstellung über ein Netzwerk sind ihre konkreten Bedingungen zu beachten.

Die installierte Version ist dabei entscheidend. Redis Open Source bis 7.2 blieb unter BSD-3-Clause; Redis Community Edition von 7.4 bis 7.8 bot RSALv2 oder SSPLv1, aber keine AGPLv3-Option. Ein intern betriebener, unveränderter Cache und ein öffentlich angebotener Datenbankdienst werfen daher unterschiedliche Lizenzfragen auf, selbst wenn beide dieselben Befehle verwenden.

Wo unterscheiden sich die Funktionen?

Bei einfachen Schlüsseln, Ablaufzeiten, Listen oder Mengen überschneiden sich die Einsatzgebiete stark. Deutlicher wird der Unterschied, wenn eine Anwendung Suchindizes, Abfragen über JSON-Dokumente oder Zeitreihenbefehle nutzt. Redis Open Source 8 bündelt diese Fähigkeiten mit probabilistischen Strukturen in seiner Distribution. Das spart bei entsprechenden Anwendungen die getrennte Auswahl und Pflege solcher Erweiterungen.

Valkey unterstützt ebenfalls Module; JSON, Suche und Bloom-Filter können darüber verfügbar sein. Ob ein Modul die benötigten Befehle, Datenformate und Betriebsfunktionen abdeckt, hängt jedoch von der gewählten Erweiterung und Bereitstellung ab. Ein gemanagter Valkey-Dienst muss nicht dieselben Module anbieten wie eine selbst betriebene Installation. Für eine bestehende Anwendung zählt deshalb die konkrete Befehlsliste mehr als die allgemeine Bezeichnung „Redis-kompatibel“.

Bei Queues sollte zusätzlich das verwendete Modell betrachtet werden: Eine einfache Liste, Streams mit Consumer-Gruppen und Anwendungsskripte stellen unterschiedliche Anforderungen an den Zielserver. Für eine Primärdatenbank kommen Persistenz, Replikation und die Wiederherstellung nach einem Ausfall hinzu. Diese Eigenschaften bestimmen, ob Daten nach einem Wechsel nur neu aufgebaut werden können oder vollständig erhalten bleiben müssen.

Wie weit reicht die Migrationskompatibilität?

Ein bestehender Redis-Client kann über das RESP-Protokoll mit Valkey sprechen. Die Valkey-Migrationsanleitung beschreibt darüber hinaus kompatible Konfigurationen sowie RDB- und AOF-Dateien für Redis OSS bis 7.2. Für Datendateien aus Redis Community Edition ab 7.4 gilt diese Zusage ausdrücklich nicht; deren Übernahme benötigt einen anderen Weg.

Diese Versionsgrenze trennt zwei Migrationspfade. Von einer älteren Redis-OSS-Installation kann eine Dateiübernahme möglich sein, sofern Sicherung und Startkonfiguration zusammenpassen. Bei neueren Redis-Versionen ist das Kopieren eines RDB-Abbilds kein belastbarer Standardweg. Dann muss die Übertragung auf Schlüssel- oder Anwendungsebene geplant und auf Vollständigkeit geprüft werden.

Protokollkompatibilität garantiert zudem kein identisches Verhalten jeder Anwendung. Clients können beispielsweise Serverversionen abfragen; Valkey gibt aus Kompatibilitätsgründen auch einen älteren Redis-Versionswert aus und bietet eigene Felder zur Erkennung an. Skripte, ACL-Regeln und Module verdienen eine gesonderte Prüfung. Bei schreibenden Queues und Primärdatenbanken muss der Umschaltpunkt festlegen, wie während der Datenübernahme eintreffende Änderungen behandelt werden. Ein leer gestarteter Cache hat dieses Problem nur dann in geringerem Maß, wenn seine vollständige Wiederbefüllung akzeptabel ist.

Was sagen die Kubernetes-Messungen?

Die Hochschularbeit zum Kubernetes-Vergleich testete Redis 7.2.7 und Valkey 8.0.2 als einzelne Instanzen mit gleichen Ressourcenlimits. Sie verwendete Redis-ähnliche Zugriffsmuster, mehrere Parallelitätsstufen und wiederholte Läufe. Damit liefert sie einen kontrollierten Vergleich dieser Konfigurationen, keine Messung von Redis 8 gegen eine aktuelle Valkey-Version.

Bei der leseintensiven Last lag Valkeys Durchsatz mit 100 gleichzeitigen Verbindungen 29 Prozent unter dem von Redis, mit 1.500 Verbindungen dagegen 20 Prozent darüber. Bei der ausgeglicheneren Lese-Schreib-Last war Redis über weite Teile des getesteten Bereichs vorn; bei hoher Parallelität lagen die Werte näher beieinander. Schon der Wechsel des Lastprofils verändert somit die Aussage eines einzelnen Durchsatzwerts.

Die Grenzen des Aufbaus sind für den Betrieb wesentlich: Persistenz war deaktiviert, Cluster und Replikation wurden nicht gemessen, und die CPU-Zuteilung war begrenzt. Die Ergebnisse erfassen damit weder den Aufwand dauerhafter Speicherung noch das Verhalten einer hochverfügbaren Queue oder Primärdatenbank. Auch Latenz und Ressourcenverbrauch müssen neben dem Durchsatz betrachtet werden, wenn Antwortzeiten oder Betriebskosten die eigentliche Entscheidung bestimmen.

Welche Kombination passt zur Anwendung?

Für einen austauschbaren Cache mit gemeinsamen Grundbefehlen spricht Valkey besonders dann, wenn BSD-3-Clause und ein unkomplizierter Wechsel von Redis OSS bis 7.2 zählen. Bei einer Queue bleibt Valkey ebenfalls eine plausible Wahl, sofern Client, Skripte und Wiederanlauf mit dem tatsächlich verwendeten Befehlsumfang funktionieren. Die einfache Lizenz allein sagt nichts über verlorene oder doppelt verarbeitete Nachrichten bei einer Umschaltung aus.

Redis Open Source 8 liegt näher, wenn integrierte Suche, JSON, Zeitreihen oder probabilistische Strukturen fester Bestandteil des Datenmodells sind. Die AGPLv3-Option macht die Gegenüberstellung nicht zu „Open Source gegen proprietär“; maßgeblich sind die Pflichten der gewählten Lizenz und die Art der Bereitstellung. Für einen gemanagten Dienst verdient diese Prüfung besonderes Gewicht.

Bei einer Primärdatenbank sollte die Wahl schließlich an der geforderten Wiederherstellbarkeit hängen. Entscheidend sind der zulässige Datenverlust, das Verhalten während eines Ausfalls und die Übertragbarkeit vorhandener Daten. Die Lizenz grenzt die zulässigen Wege ein, Funktionen und Dateiformate bestimmen den Migrationsaufwand, und Messungen unter der eigenen Last zeigen erst den nötigen Kapazitätsspielraum.

Lesen Sie auch:

• Source by Webflow arbeitet direkt am Code – Zugang gibt es nur auf Bewerbung
• Coursera oder LinkedIn Learning: 1.500 Labore gegen 18.000 Videokurse
• OpenAI API oder Claude API: Erst die Aufgabe macht den Tokenpreis vergleichbar