Valkey: der beste Open-Source-Drop-in-Ersatz für Redis


Im März 2024 wechselte Redis Inc. von seiner permissiven BSD-Lizenz zu RSALv2/SSPLv1, was für kommerzielle Engineering-Teams zu einem echten Compliance-Risiko geführt hat.

Als Reaktion darauf hat die OSS- und Nutzer-Community Redis fast sofort in eine neue Option namens Valkey geforkt. Valkey wurde im selben Monat unter der Linux Foundation gestartet und bietet einen echten Drop-in-Ersatz, der die von Redis verursachte rechtliche Problematik umgeht.
OVHcloud_Cloud_Database_Business_600x400@2x.png

Redis ersetzen, ohne Ihre Apps neu aufzubauen

Redis hat sich aus gutem Grund einen Ruf als bevorzugter In-Memory-Datenspeicher erarbeitet. Es ist schnell, flexibel und (war) wirklich offen. Doch eine Reihe von Lizenzentscheidungen seit März 2024 hat Technik- und Rechtsteams dazu gezwungen, ihre Risiken neu zu bewerten und nach einer Cache-Alternative zu suchen. 

Die Reaktion der Communities auf die Lizenzänderungen von Redis bestand darin, nach schnellen, koordinierten und gut ausgestatteten Optionen zu suchen, hauptsächlich nach einem Fork aus den Communities. Valkey ist kein Protest-Fork mit wenig Unterstützung. Valkey profitiert von erheblicher institutioneller Unterstützung und aktiver Entwicklung – es ist also eine vollständig BSD-lizenzierte Alternative mit voller Kompatibilität zur Redis-Codebasis, die die meisten Teams bereits verwenden.
171787e4-7090-45ca-9346-5fafb7c170fe_ima_81ddb684.png

Valkey: Projekt und Dienst mit integrierter Sicherheit

Offene Governance, Kompatibilität, verwaltete Resilienz und vertraute Grundlagen
[object Object]
Community-gesteuert
[object Object]
Drop-in-Kompatibilität
[object Object]
Verwaltete Resilienz
[object Object]
Vertraute Grundlagen

Warum Entwickler im Jahr 2026 nach einer Redis-Alternative suchen

Erklärung zur Redis-Lizenzänderung von 2024

Während seiner Existenz wurde Redis meistens unter der BSD 3-Clause-Lizenz vertrieben, einer der freizügigsten Open-Source-Lizenzen. Man konnte Redis uneingeschränkt nutzen, modifizieren und kommerzielle Produkte darauf aufbauen. Das änderte sich am 20. März 2024, als Redis Inc. ankündigte, dass Redis 7.4 und alle zukünftigen Funktions-Releases auf ein Dual-Lizenz-Modell umgestellt werden: RSALv2 (Redis Source Available License v2) und SSPLv1 (Server Side Public License). Keine der beiden Lizenzen ist von der Open Source Initiative (OSI) genehmigt, und beide legen explizite Beschränkungen für die Nutzung der Software in kommerziellen und Cloud-Umgebungen fest.

Warum SSPL ein Compliance-Risiko für kommerzielle Produkte darstellt

SSPL wurde ursprünglich von MongoDB geschrieben, um zu verhindern, dass Cloud-Anbieter verwaltete Datenbankdienste anbieten, ohne ihrerseits einen Beitrag zu leisten. Das Kernproblem für kommerzielle Produktteams ist Abschnitt 13: Wenn Ihre Anwendung als Dienst zur Verfügung gestellt wird und auf SSPL-lizenzierter Software basiert, müssen Sie möglicherweise den Quellcode Ihres gesamten Dienst-Stacks veröffentlichen, einschließlich proprietärer Komponenten, die Sie entwickelt haben.

Für die meisten Engineering-Teams ist diese Verpflichtung bei der Entwicklung von Funktionen und Alternativen ein Ausschlusskriterium. Selbst wenn die Rechtsberatung zu dem Schluss kommt, dass das Risiko in der Praxis gering ist, schafft allein die Unsicherheit Reibungspunkte bei Beschaffung, Sicherheitsüberprüfungen und Verträgen mit Firmenkunden. RSALv2 verschärft dies, indem es die Verwendung in konkurrierenden Produkten oder Funktionen ausdrücklich untersagt und Redis Inc. einen weiten Ermessensspielraum darüber gibt, was Wettbewerb darstellt... was Redis-Nutzer erneut einem rechtlichen Minenfeld aus rechtlichen Herausforderungen aussetzt – Herausforderungen, die leicht umgangen werden können, indem stattdessen Code verwendet wird, der unter einer OSI-zugelassenen Lizenz steht.

Redis 7.2 beibehalten: die versteckte Sicherheitsschuld

Die letzte Redis-Caching-Version unter BSD war Version 7.2. Einige Teams entscheiden sich dafür, bei dieser Version zu bleiben, anstatt die neuen Lizenzbedingungen zu akzeptieren. Es ist wohl eine pragmatische kurzfristige Entscheidung, die langfristige Kosten verursacht. Redis 7.2 erhält keine Sicherheits-Patches oder Fehlerbehebungen mehr von Redis Inc., was bedeutet, dass alle CVEs, die nach der Lizenzänderung entdeckt wurden, in diesem Zweig nicht behoben werden. Für Teams, die Redis 7.2 Caching in einer Produktionsumgebung betreiben, sensible Daten verarbeiten oder unter Rahmenwerken wie NIS2 oder SOC 2 arbeiten, ist dies kein theoretisches Risiko. Das Festhalten an Redis 7.2 schafft eine aktive Compliance-Lücke, die mit jedem Monat, der vergeht, größer wird.

Warum AGPLv3 für Redis 8.0 keine dritte Option ist

Mit der Veröffentlichung von Redis 8.0 im Jahr 2025 vollzog Redis Inc. einen weiteren Lizenzschritt, diesmal hin zur AGPLv3, die OSI-zertifiziert ist. Das ist ein echter Fortschritt in Bezug auf die Legitimität von Open Source und behebt einen der Hauptkritikpunkte an der Änderung von 2024. Allerdings ist die AGPLv3 eine starke Copyleft-Lizenz und bringt ihre eigenen Komplikationen für kommerzielle Teams mit sich.

Jede Software, die über ein Netzwerk mit einer AGPLv3-lizenzierten Komponente interagiert, kann die Anforderung auslösen, den Quellcode dieser Software unter derselben Lizenz zu veröffentlichen. Für proprietäre SaaS-Produkte bleibt dies eine erhebliche Einschränkung in Bezug auf Alternativen. Mehrere prominente Stimmen in der Branche, darunter Mitwirkende am Valkey-Projekt, haben angemerkt, dass Redis durch die AGPLv3 (obwohl prinzipientreuer als die SSPL) Redis immer noch zu einer anderen Kategorie als wirklich permissive Open-Source-Alternativen gehört.

App-Verhalten bewahren und Datenstandort kontrollieren

BSDRESP2Clustering
Seit seiner Gründung qualifiziert sich Valkey als Drop-in-Ersatz, da sich die Kompatibilität auf das Redis-Protokoll, Befehle, Client-Bibliotheken, Persistenz und Clustering erstreckt. Für eine unterstützte Anwendung kann diese Abdeckung Codeänderungen reduzieren und es Teams ermöglichen, die Validierung anhand desselben Zugriffsmodells zu starten. 

Multi-Node-Layouts können auch vertraute Resilienz-Muster bewahren. Kompatibilität erfordert dennoch Tests. Module, versionsspezifisches Verhalten und ungewöhnliche Befehlskombinationen können zu einer anderen Antwort führen. Speicherdesign, Kundeneinstellungen und Topologie können sich ebenfalls auf die Stabilität oder den Durchsatz auswirken. Man sollte bei keiner Migration davon ausgehen, dass jeder Grenzfall schneller abläuft oder sich identisch verhält. Die OSI-genehmigte Lizenz von Valkey bietet kommerziellen Teams eine dauerhafte Open-Source-Alternative zu Redis, ohne die Anwendungsarchitektur an restriktive Bedingungen zu binden. 

Die Wahl der Bereitstellung fügt dann eine betriebliche Dimension hinzu. Ein verwaltetes europäisches Angebot kann Thread-Verarbeitung, resiliente Knotenplatzierung und kontrolliertes Datenhosting kombinieren. Dieser Ansatz unterstützt die europäische Datensouveränität, indem Standort, Zugriff und vertragliche Abwicklung sichtbar bleiben, während die routinemäßige Plattformverwaltung reduziert wird.

2c541d44-5950-4028-b9eb-d3e5efacab26_ima_180e373b.png
Bei der Gründung von Valkey haben unter anderem die weltweit größten Cloud-Anbieter und Technologieunternehmen mitgewirkt – einschließlich Datenbankgiganten. Zusammen decken sie den Großteil der globalen Cloud-Infrastruktur ab, und dies ist keine passive Befürwortung. Diese Organisationen haben aktive Ingenieure, die zur Codebase beitragen. Es ist üblich, dass große Cloud-Anbieter Redis durch Valkey als Standard für ihre Funktionen ersetzen. Die Breite der Unterstützung bedeutet, dass Valkey über die technischen Ressourcen, die Kapazität für Sicherheitsreaktionen und das langfristige Engagement für die Roadmap verfügt, die ein unabhängiger Community-Fork selten erreicht.

Valkey stammt aus der Redis 7.2-Codebase, daher bieten seine API, Befehle, Clients und Persistenzformate eine vertraute technische Grundlage. Viele Anwendungen können etablierte Zugriffsmuster beibehalten, aber die Kompatibilität hängt von der gewählten Version und Konfiguration ab. Testen Sie Skripte, Transaktionen, Pub/Sub-Verhalten, Cluster-Operationen und ungewöhnliche Befehle mit repräsentativem Anwendungsverkehr. Auch Konsistenzerwartungen erfordern Aufmerksamkeit. Bestätigen Sie das Replikationsverhalten, die Failover-Handhabung und die Lesesemantik in jedem Betriebsmodus. Dokumentation und Support-Matrizen können die Untersuchung eingrenzen, während Anwendungstests bestimmen, ob die gewählte Option produktionsreif ist.

In unabhängigen Benchmarks behauptet sich Valkey gegenüber Redis bei Standard-Workloads. Ein Hyperscale-Benchmark verglich Valkey 8.1 mit Redis 8.2 bei 50 Millionen Einträgen in sortierten Mengen.

DragonflyDB führt bei einigen Tests beim einfachen Single-Node-Durchsatz, aber dieser Vorteil verringert sich in Cluster-Konfigurationen erheblich. Die Feature-Parität mit Redis 7.2 ist vollständig, und die Roadmap von Valkey hat seitdem Verbesserungen beim Multi-Threading und Effizienzgewinne beim Speicher hinzubekommen, sodass es bei einigen Workloads die Version übertrifft, von der es abgeleitet wurde.

DragonflyDB könnte für Teams attraktiv sein, die über eine moderne Architektur für hohen Durchsatz, vertikale Skalierung oder Speichereffizienz nachdenken. Dragonfly verwendet jedoch ein anderes internes Design, und architektonische Unterschiede können sich auf Clustering, Persistenz, operative Tools und Konsistenz auswirken. Diese Faktoren können es für einige bestehende Umgebungen zu einem weniger direkten Ersatz machen. 

Andere Technologien können für spezielle Anforderungen geeignet sein, wie z. B. Vektorsuche oder intermittierende serverlose Workloads. Die Recherche kann technisches Material umfassen, das über Google, Community-Diskussionen und Anbieterdokumentationen gefunden wurde, aber primäre Dokumentationen und kontrollierte Tests sollten stärker gewichtet werden. Vergleichen Sie jede Alternative hinsichtlich Anwendungsänderung, operativer Reife, verfügbarem Support, Governance und Gesamtaufwand für die Migration. Die geeignete Technologie ist diejenige, die gemessene Anforderungen mit akzeptablen Lizenzierungs- und Betriebsrisiken erfüllt.
Bei der Gründung von Valkey haben unter anderem die weltweit größten Cloud-Anbieter und Technologieunternehmen mitgewirkt – einschließlich Datenbankgiganten. Zusammen decken sie den Großteil der globalen Cloud-Infrastruktur ab, und dies ist keine passive Befürwortung. Diese Organisationen haben aktive Ingenieure, die zur Codebase beitragen. Es ist üblich, dass große Cloud-Anbieter Redis durch Valkey als Standard für ihre Funktionen ersetzen. Die Breite der Unterstützung bedeutet, dass Valkey über die technischen Ressourcen, die Kapazität für Sicherheitsreaktionen und das langfristige Engagement für die Roadmap verfügt, die ein unabhängiger Community-Fork selten erreicht.

Passen Sie das Betriebsmodell an Ihre Anforderungen an

Verwaltetes Valkey

Managed Databases für Valkey eignet sich für Unternehmen, die einfache Abläufe und vorhersehbare Infrastrukturkosten möchten. OVHcloud verwaltet hohe Verfügbarkeit, Wartung, Überwachung und Backups und reduziert so den internen Arbeitsaufwand für den Betrieb eines resilienten Dienstes. Durch die enthaltene Bandbreite und IOPS wird die Budgetierung ebenfalls übersichtlicher. Dies ist eine praktische Standardeinstellung, wenn Plattformteams Valkey benötigen, ohne jede operative Aufgabe selbst zu übernehmen.

Selbstverwaltetes Valkey

Die Selbstverwaltung bietet Kontrolle über Softwareversionen, Topologie, Sicherheitseinstellungen und Bereitstellungsort. Sie kann für Unternehmen mit spezifischen Anforderungen oder etablierten Datenbankabläufen geeignet sein. Die Nachteile sind ebenso real: Das interne Team ist für Upgrades, Backups, Observability, Failover-Tests und die Reaktion auf Vorfälle verantwortlich. Community-Ressourcen helfen, ersetzen jedoch keinen verantwortlichen Produktionssupport oder operative Kapazitäten.

KeyDB

KeyDB kann für Teams geeignet sein, die sich für eine Multithread-Ausführung für bestimmte Speicherdaten-Workloads und Latenzziele interessieren. Bewerten Sie Kompatibilität, Release-Aktivität, Projektgesundheit und verfügbaren Support, bevor Sie sich festlegen. Führen Sie Benchmarks für die tatsächliche Anwendung durch, anstatt davon auszugehen, dass ein Architekturmerkmal jedes Anfragemuster verbessern wird. Informationen, die mit einem Gründer oder einer frühen Projekterklärung verknüpft sind, sollten ebenfalls anhand der aktuellen Dokumentation überprüft werden.

Spezialisierte Alternativen

Serverless-Dienste können die Kapazitätsplanung für intermittierende Workloads reduzieren, während Vektordatenbanken die Ähnlichkeitssuche und andere spezialisierte Datenmodelle unterstützen. Alternative In-Memory-Software kann eventuell auf spezifische Durchsatz- oder Persistenzanforderungen abzielen. Diese Tools können definierte Probleme lösen, sind aber nicht unbedingt sofort einsatzbereite Alternativen. Berücksichtigen Sie Anwendungsänderungen, Datenverschiebung, betriebliche Zuständigkeit und langfristige Kosten, bevor Sie sich statt Valkey für diese Alternativen entscheiden.

Wählen Sie einen Migrationspfad, der zu Ihren Ausfallzeiten passt

RDBAOFRESP2
Es gibt zwei praktische Ansätze für die Migration von Redis zu Valkey. Der für Sie Richtige hängt davon ab, ob Sie ein Wartungsfenster tolerieren können. Die Dump/Restore-Methode ist der richtige Ansatz für kleinere Datensätze oder nicht kritische Umgebungen. Da Valkey dasselbe RDB-Snapshot-Format wie Redis verwendet, können Sie eine dump.rdb-Datei aus Ihrer Redis-Instanz exportieren und ohne Konvertierungsschritt direkt in Valkey laden.

Fahren Sie Ihre Redis-Instanz zur Konsistenz herunter, kopieren Sie die Datei in Ihr Valkey-Datenverzeichnis, starten Sie Valkey, und die Sache ist erledigt. Die gesamte Migrationszeit ist proportional zur Datensatzgröße, nicht zur Anwendungskomplexität. Für Produktionsumgebungen, in denen Ausfallzeiten nicht akzeptabel sind, ist die Live-Replikation der sicherere Weg. Valkey kann mithilfe des Standard-REPLICAOF-Befehls als Replikat einer laufenden Redis 7.2-Instanz konfiguriert werden.

Sobald das Replikat vollständig synchronisiert ist, aktualisieren Sie die Verbindungszeichenfolge Ihrer Anwendung, damit sie auf Valkey verweist, stufen es zum Primärsystem hoch und nehmen die Redis-Instanz außer Betrieb. Da beide Systeme dasselbe Replikationsprotokoll verwenden, ist dieser Prozess sauber und wurde in der Produktion von Teams bei allen großen Cloud-Anbietern umfassend getestet.
[object Object]

Erstellen Sie ein vierteiliges Framework für die Migrationsbereitschaft

1. Anwendungskompatibilität

Machen Sie eine Aufstellung aller verwendeten Befehle, jeder Client-Bibliothek und jeder Protokollversion. Erfassen Sie RESP3-Funktionen, Lua-Skripte, Transaktionen, Pub/Sub-Muster, JSON- oder Modulabhängigkeiten sowie anwendungsspezifisches Timeout-Verhalten. Ein kompatibler Kern besagt nicht, dass sich jede Erweiterung auf die gleiche Weise verhält. Vergleichen Sie die aktuelle Umgebung mit der Zielversion und testen Sie repräsentative Anfragen. Beziehen Sie Fehlerbehandlung, Verbindungspooling und Wiederholungslogik mit ein. Wenn eine Anwendung auf Technologie angewiesen ist, die von einem externen Plugin bereitgestellt wird, überprüfen Sie dessen Wartungsstatus separat. Diese Aufstellung macht aus allgemeiner Kompatibilität einen Nachweis auf Basis spezifischer Anforderungen.

2. Die Datenintegrität schützen

Messen Sie den Datensatz vor der Migration, einschließlich Schlüsselanzahl, Ablaufverteilung, Objektgrößen und Spitzen-Speicherverbrauch. Das Ziel benötigt ausreichend Speicher für den Normalbetrieb, die Replikation und den temporären Overhead während der Synchronisierung oder Persistenz. Überprüfen Sie Snapshot- und Append-Only-Einstellungen, anstatt sie ohne Analyse zu kopieren. Vergleichen Sie nach der Übertragung die Schlüsselanzahl, Stichprobenwerte und das Ablaufverhalten. Prüfungen auf Anwendungsebene können Probleme aufdecken, die bei reinen Summen übersehen werden, wie etwa fehlerhafte Sitzungen oder ein unvollständiger Warteschlangenzustand. Teilen Sie die Abnahmekriterien vor der Umstellung den Service-Eigentümern mit, damit alle dieselbe Definition eines gültigen Datensatzes verwenden.

3. Die Zieltopologie abbilden

Dokumentieren Sie, ob die aktuelle Plattform eigenständig, repliziert oder über einen Cluster verteilt ist. Erfassen Sie jeden Knoten, jede Netzwerkroute, jede Sicherheitsregel, jede DNS-Abhängigkeit und jeden physischen Standort. Diese Karte hilft den Teams dabei, ein Ziel-Layout auszuwählen, das die Anforderungen an die Ausfallsicherheit widerspiegelt, anstatt historische Entscheidungen zu reproduzieren. Konnektivitätstests sollten die Anwendung, Überwachungssysteme und Verwaltungstools abdecken. Überprüfen Sie bei einem verteilten Workload die Slot-Handhabung, die Replikat-Platzierung und das Verhalten bei Knotenverlust. Die Anforderungen an den Datenspeicherort können auch bestimmen, welche Regionen oder Verfügbarkeitszonen akzeptabel sind.

4. Kontrollieren Sie die Umstellung

Etablieren Sie Basiswerte für Latenz, Fehlerrate und Ressourcen, bevor Sie den Datenverkehr verschieben. Definieren Sie Überwachungsschwellenwerte, Rollback-Kriterien und Entscheidungsträger, solange der Dienst stabil ist. Dies verhindert, dass Teams während eines Vorfalls über akzeptables Verhalten diskutieren müssen. Verschieben Sie den Datenverkehr phasenweise, sofern die Architektur dies zulässt. Beginnen Sie mit internen oder risikoarmen Workloads, beobachten Sie Client-Fehler und vergleichen Sie die Ergebnisse, bevor Sie den Anteil erhöhen. Halten Sie die Quelle wiederherstellbar, bis die Validierung abgeschlossen ist. Eine sichere Umstellung hängt von gemessenen Nachweisen, klarer Verantwortlichkeit und einem Rollback-Weg ab, nicht allein von Kompatibilitätsbehauptungen.

Warum sollte man sich für OVHcloud Managed Databases für Valkey entscheiden

Valkey in der Produktion zu betreiben, ist eine Entscheidung. Zu entscheiden, wie man es für Stabilität betreibt, ist eine andere. Die Selbstverwaltung eines In-Memory-Clusters, einschließlich der Handhabung von Replikation, Failover, Patching und Backups, erhöht den betrieblichen Aufwand, der nur schlecht skaliert, wenn Ihr Team und Datensatz anwächst. OVHcloud Managed Databases für Valkey nimmt Ihnen diese Last vollständig ab, mit einem vollständig verwalteten Dienst, der auf drei Dingen basiert, die europäische Engineering-Teams konsequent benötigen: Ausfallsicherheit, planbare Kosten und Datensouveränität.

Eine der ständigen Frustrationen bei Cloud-verwalteten Datenbanken ist die Unvorhersehbarkeit der Abrechnung. Denken Sie an Gebühren, die bei hoher Auslastung in die Höhe schnellen, weil Bandbreite, IOPS und Backup-Speicher separat abgerechnet werden. Das Preismodell von OVHcloud bündelt diese Kosten in einer monatlichen Pauschale. Bandbreite, E/A-Operationen und automatisierte Backups sind enthalten, sodass die Kosten, die Sie bei der Beschaffung sehen, die Kosten sind, die Sie in der Produktion zahlen. Für Finanz- und Beschaffungsteams in Scale-ups, die knappe Infrastrukturbudgets verwalten, macht dies die Kapazitätsplanung deutlich übersichtlicher.
OVHcloud_Baremetal_600x400.png
Blick in die Zukunft – OSS-Lizenzen im Auge behalten
Die Redis-Lizenzsituation ist kein Einzelfall in der Open-Source-Lizenzlandschaft. Da Open-Source-Projekte reifen und die Unternehmen dahinter versuchen, wichtige Aspekte zu Geld zu machen, sind Lizenzänderungen zu einem immer häufigeren Druckpunkt für Engineering-Teams geworden. Die Grundlagen der Funktionsweise von Open-Source-Lizenzen zu verstehen und zu wissen, worauf man achten muss, ist heute eine notwendige Fähigkeit für alle, die für einen Produktionstechnologie-Stack verantwortlich sind.
Valkey erkunden