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.

Redis ersetzen, ohne Ihre Apps neu aufzubauen
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.

Valkey: Projekt und Dienst mit integrierter Sicherheit
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
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.

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.
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.
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
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]](https://assets.ovhcloud.com/1fiX676v6wSp4t82zXEm6hhry_sNzAzOTNmMTIyZWVkYzg0/555a10a6-71ae-4d77-959e-b2a8dc0e9831_ima_c8d0550b.png)
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
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.
