6 Min. Lesezeit

Valkey 9 liefert seit Oktober 2025 über eine Milliarde Requests pro Sekunde im Cluster und hat Redis als Default in den wichtigsten Managed-Cache-Diensten abgelöst. Nach 18 Monaten ist aus dem Lizenz-Fork ein technisch eigenständiges Projekt geworden – und Redis 8 holt das nur teilweise auf.

Das Wichtigste in Kürze

• Fork-Geschwindigkeit: Acht Tage nach der Redis-SSPL-Ankündigung im März 2024 stand Valkey unter der Linux Foundation – getragen von AWS, Google, Oracle, Alibaba, Ericsson, Huawei und Tencent (TechCrunch, 2024).
• Valkey 9 GA: Seit 21. Oktober 2025 verfügbar. Ein Cluster bewältigt über 1 Milliarde Requests pro Sekunde, Einzelknoten-Throughput steigt um bis zu 40 Prozent gegenüber Valkey 8.1 (Linux Foundation, 2025).
• Cloud-Default: AWS ElastiCache und Google Memorystore haben Valkey zum Standard für neue Instanzen gemacht. Valkey verzeichnet rund 1 Million Container-Pulls pro Woche (The Stack, Februar 2026).
• Redis 8 Gegenoffensive: Im Mai 2025 brachte Redis Labs Version 8 mit tri-licensing (RSALv2, SSPLv1, AGPLv3) – Rückkehr zu Open Source, aber unter Copyleft statt BSD.
• Migration: Der Wechsel von Redis 7.2 auf Valkey ist laut Maintainern ein „seamless patch“. AWS bietet In-Place-Upgrades ohne Downtime.

18 Monate Valkey: Vom Protest-Fork zum Default

Am 20. März 2024 wechselte Redis Labs von der BSD-Lizenz auf die Server Side Public License (SSPLv1) – ein Schritt gegen Hyperscaler, die Redis als Managed-Service verkauften, ohne zum Projekt beizutragen. Acht Tage später lag Valkey als Fork von Redis 7.2.4 auf GitHub, mit Madelyn Olson (AWS, vorher Redis-Maintainerin) als treibender Figur und der Linux Foundation als Dach.

Was als Lizenz-Protest begann, ist 18 Monate später eine eigenständige Codebase. Valkey 8.0 brachte Ende 2024 I/O-Threading, Valkey 8.1 verbesserte TLS-Handshakes um rund 300 Prozent. Valkey 9.0 ging am 21. Oktober 2025 GA – mit atomarer Slot-Migration, Hash-Field-Expiration und Multi-Database-Support im Cluster-Mode. Keines dieser Features existiert in Redis 8 in vergleichbarer Form.

„Wir haben es als kritisch angesehen, die BSD-Lizenz zu behalten. Die meisten Anwender wollen sich nicht durch die Feinheiten von LGPL oder SSPL arbeiten – sie wollen einfach bauen. Wir wollten da weitermachen, wo wir aufgehört hatten, ohne die Gefahr eines weiteren Lizenzwechsels.“
– Madelyn Olson, Principal Engineer AWS und Valkey-Maintainerin (The Stack, Februar 2026)

Die Backing-Struktur ist ungewöhnlich breit: Neben AWS stehen Google, Oracle, Alibaba, Ericsson, Huawei und Tencent als Corporate Sponsors auf der Valkey-Webseite. Für ein Infrastruktur-Projekt ist das eine seltene Allianz – und ein deutlicher Unterschied zu Forks, die an einem einzelnen Anbieter hängen. Wer die Geschichte von OpenStack, MariaDB oder OpenTofu kennt, weiß: Multi-Vendor-Governance unter einer neutralen Foundation ist der wichtigste Faktor für Langzeit-Stabilität eines Forks. Ein einzelner Anbieter kann jederzeit die Prioritäten verschieben, ein Konsortium mit sieben Big-Tech-Akteuren hat dagegen eingebaute Gewichte und Gegengewichte.

Unter der Kapuze hat das Valkey-Team zudem die Code-Ownership anders strukturiert als Redis unter dem alten Modell. Reviews laufen über ein öffentliches Maintainer-Board, Patches kommen von AWS-, Google- und Alibaba-Engineers in ähnlicher Frequenz. Das ist keine Garantie für bessere Code-Qualität, aber ein stabileres Fundament gegen strategische Einzelentscheidungen. Wer sich 2024 bei der SSPL-Ankündigung fragte, ob ein solcher Schritt sich wiederholen könnte, findet in dieser Governance-Struktur die klarste Antwort der Branche.

Valkey 9 vs. Redis 8: Wo die Unterschiede wirklich liegen

Der häufigste Fehler in der Debatte ist die Annahme, es gehe nur um die Lizenz. Technisch laufen die Projekte seit Oktober 2025 auseinander – und die Unterschiede betreffen produktive Workloads.

Quellen: valkey.io, redis.io, AWS Database Blog, Google Cloud Blog (2025-2026)

Der entscheidende Punkt ist die atomare Slot-Migration. Klassisches Redis-Cluster-Resharding erzeugt kurzfristige Redirect-Errors bei Clients, die in Hochlast-Umgebungen als Timeouts durchschlagen. Valkey 9 verschiebt Slots ohne Downtime und ohne Client-Fehler – ein Feature, das besonders für Multi-Tenant-Cache-Cluster den Unterschied macht.

Die Zahlen hinter dem Benchmark-Streit

Beide Projekte werben mit Performance-Sprüngen und beide Zahlen stimmen für sich genommen. Redis 8 meldet gegenüber Redis 7.4 bis zu 87 Prozent schnellere Commands und bis zu doppelten Durchsatz. Valkey 9 meldet gegenüber Valkey 8.1 bis zu 40 Prozent mehr Throughput – und bringt den Cluster erstmals über die Milliarden-Grenze.

Wer die beiden Zahlen vergleichen will, läuft in eine Falle. Redis 8 vergleicht sich mit der eigenen Vorversion 7.4 auf Einzelknoten-Ebene. Valkey 9 misst Cluster-weite Skalierung. Der einzige belastbare Vergleichspunkt sind unabhängige Benchmarks – und die bestätigen bislang den Valkey-Trend: Im MaiCoin-Benchmark erreichte Valkey 8.0.1 höhere Throughput-Werte und bessere p99-Latenzen als Redis 7.1.0 bei identischer Hardware.

Für Teams, die heute eine Entscheidung treffen, ist der wichtigere Indikator nicht der Prozentsatz, sondern die Feature-Velocity. Valkey hat in 18 Monaten drei Major-Releases geliefert. Redis 8 war die Rückkehr zur Open-Source-Fahne, noch nicht der Beleg für ein nachhaltiges Release-Tempo.

Unter der Haube von Valkey 9 stecken drei technische Neuerungen, die in Benchmarks eine größere Rolle spielen als die offizielle Throughput-Zahl. Memory Prefetching für Pipelining-Commands bringt laut Release-Notes rund 40 Prozent höheren Durchsatz bei gebatchten Operationen. Zero-Copy-Responses für große Antworten sparen bis zu 20 Prozent Overhead, weil Daten nicht mehr zwischen Kernel- und Userspace kopiert werden. Und SIMD-Optimierungen für BITCOUNT und HyperLogLog machen bestimmte Analytics-Queries bis zu 200 Prozent schneller. Diese drei Optimierungen zielen auf Workloads, die Redis-Nutzer seit Jahren als Bottlenecks kannten – Analytics auf Bitfields, Echtzeit-Aggregationen, große Pipelines in Batch-Jobs.

Was die Cloud-Provider jetzt tun

Die klarste Adoption-Kurve liefern die Hyperscaler. AWS hat ElastiCache for Valkey bereits 2024 veröffentlicht, macht Valkey zum Default für neue Cluster und bietet einen managed Upgrade-Pfad für bestehende Redis-Installationen. Google Cloud hat Memorystore for Valkey 9.0 zur GA-Version erklärt, Oracle OCI hat mit OCI Cache einen eigenen Managed-Service gestartet. In allen drei Fällen bedeutet „Valkey als Default“: Wer nicht aktiv widerspricht, bekommt Valkey – nicht Redis.

Die Adoption-Zahlen stützen diesen Trend. Valkey verzeichnet laut aktuellen Docker-Hub-Daten rund 1 Million Container-Pulls pro Woche, insgesamt über 70 Millionen seit dem Fork. Das ist keine Kennzahl für produktiven Einsatz, aber ein belastbarer Indikator für die Integration in CI/CD-Pipelines, lokale Entwicklung und Kubernetes-Deployments. Für ein 18 Monate altes Projekt ist diese Integrations-Dichte bemerkenswert.

Ein konkreter Fall aus der ElastiCache-Praxis: Der taiwanesische Crypto-Exchange MaiCoin hat einen Blue-Green-Upgrade von Redis OSS auf Valkey durchgeführt und dabei Redis 7.1.0, Valkey 7.2.6 und Valkey 8.0.1 unter identischer Last gemessen. Das Ergebnis: Valkey 8.0.1 lieferte den höchsten Throughput, die niedrigste p99-Latenz und die beste Memory-Effizienz. Für einen produktiven Workload mit harten Latenz-Anforderungen ist das kein Marketing-Zahlenspiel, sondern ein konkretes Kosten-Argument.

Der DACH-Markt reagiert vorsichtiger, aber nachvollziehbar. Größere Managed-Kubernetes-Umgebungen auf AWS Frankfurt und Google Cloud Frankfurt rollen Valkey 9 inzwischen für neue Cluster aus, während Bestandsinstallationen oft noch auf Redis 7.x laufen. Das entspricht dem typischen DACH-Muster: Die Lizenz-Frage wird geklärt, die Migration folgt im nächsten Capacity-Planning-Zyklus – selten in Panik, meist koordiniert mit Release-Branches oder geplanten Cluster-Upgrades.

Migration: Was „seamless patch“ in der Praxis bedeutet

Valkey 9 spricht das Redis-Protokoll (RESP) und unterstützt Redis-7.2-Clients ohne Änderungen. Das ist der wichtigste Grund, warum die Migration in vielen Fällen ohne Code-Anpassung läuft. AWS ElastiCache bietet einen managed In-Place-Upgrade-Pfad: Neue Valkey-Knoten werden im bestehenden Cluster hochgezogen, replizieren vom Redis-Primary, dann wird per Failover umgeschaltet. Downtime: null.

In der Realität gibt es drei Stolperfallen. Erstens: Redis-Stack-Module wie RedisJSON, RediSearch oder RedisBloom sind proprietär und in Valkey nicht enthalten. Wer sie nutzt, braucht entweder die Valkey-Community-Module (Valkey-JSON, Valkey-Search, Valkey-Bloom, alle unter BSD) oder bleibt bei Redis. Die Community-Module sind funktional, haben aber nicht den gleichen Feature-Stand wie die Redis-Stack-Varianten.

Zweitens: Wer auf Redis Enterprise Features wie Active-Active-Geo-Replikation setzt, findet in Valkey kein Äquivalent. Diese Workloads bleiben bei Redis oder wandern auf Alternativen wie Dragonfly oder KeyDB.

Drittens: Observability-Tools, die auf Redis-spezifische INFO-Felder parsen, brauchen gelegentlich Anpassungen. Die großen APM-Anbieter (Datadog, Grafana, New Relic) unterstützen Valkey inzwischen nativ, aber Eigenbau-Dashboards können stolpern.

Wann bei Redis bleiben – und wann wechseln

Die Entscheidung ist weniger technisch als organisatorisch. Wer Redis Enterprise oder Redis Stack Module produktiv nutzt, hat keinen pragmatischen Migrationspfad – und Redis 8 unter AGPLv3 ist für die meisten Anwendungsfälle rechtlich unproblematisch, solange der Code nicht als Service an Dritte weiterverkauft wird. Die AGPL-Viralität greift beim internen Betrieb nicht.

Wer dagegen Redis als klassischen Key-Value-Cache nutzt, Managed Services auf AWS oder Google Cloud einsetzt und keine Enterprise-Features braucht, fährt mit Valkey 9 heute technisch vorn. Die Lizenz ist permissiver, die Feature-Velocity höher, die Cloud-Integration tiefer. Und der Fall, dass ein großer Cloud-Anbieter die Unterstützung einstellt, ist bei einem Projekt mit sieben Corporate Sponsors unter der Linux Foundation deutlich unwahrscheinlicher als bei einem kommerziellen Einzelanbieter.

Für Teams, die 2026 neu starten, ist die Frage ohnehin entschieden: AWS ElastiCache und Google Memorystore erzeugen bei neuen Clustern Valkey, nicht Redis. Wer Redis will, muss explizit einen kommerziellen Vertrag abschließen.

Fazit

Die Lizenz-Debatte ist nach 18 Monaten entschieden – nicht, weil eine Seite verloren hätte, sondern weil beide Seiten zu stabilen Optionen geworden sind. Valkey 9 ist der technisch aktivere, permissiv lizenzierte Default der großen Cloud-Provider. Redis 8 ist unter AGPLv3 wieder Open Source und liefert Performance-Gewinne, hält aber mit dem Valkey-Release-Tempo nicht Schritt.

Für die meisten Cloud-Workloads in DACH ist Valkey 9 heute die risikoärmere Wahl. Wer migriert, sollte mit einem nicht-kritischen Cache starten, die Valkey-Community-Module evaluieren und die In-Place-Upgrade-Optionen des jeweiligen Managed Service nutzen. Der „seamless patch“ stimmt für 80 Prozent der Fälle – die restlichen 20 Prozent kosten Planungszeit, keine Überraschungen.

Häufige Fragen

Ist Valkey 9 vollständig Redis-kompatibel?

Valkey 9 spricht das Redis-Serialisation-Protokoll (RESP) und ist mit Redis-7.2-Clients binärkompatibel. Anwendungscode, der Standard-Commands nutzt, läuft ohne Änderungen. Inkompatibel sind Redis-Stack-Module wie RedisJSON, RediSearch und RedisBloom – dafür gibt es Valkey-Community-Äquivalente (Valkey-JSON, Valkey-Search, Valkey-Bloom), die aber funktional noch nicht vollständig deckungsgleich sind.

Was passiert mit meinen Redis-Lizenzkosten, wenn ich auf Valkey wechsle?

Valkey steht unter BSD 3-Clause und ist vollständig kostenfrei – auch für kommerzielle Nutzung und Managed Services. Managed-Service-Kosten bei AWS ElastiCache oder Google Memorystore zahlt man weiterhin, aber ohne zusätzliche Software-Lizenzgebühren. Wer bisher Redis Enterprise Subscription-Kosten hatte, spart die vollständig ein.

Kann ich zwischen Valkey 9 und Redis 8 live migrieren?

Ja, in beide Richtungen. AWS ElastiCache bietet einen managed In-Place-Upgrade-Pfad von Redis zu Valkey mit Zero-Downtime-Failover. Für Self-Hosted-Umgebungen funktioniert der Weg über Standard-Replikation: Valkey-Replica gegen Redis-Primary hochziehen, Replikation abwarten, Failover auslösen. Die RESP-Kompatibilität macht beide Richtungen gangbar, solange keine proprietären Redis-Module im Spiel sind.

Welche Rolle spielen Dragonfly und KeyDB in dieser Debatte?

Dragonfly und KeyDB sind Redis-kompatible Reimplementierungen, die unabhängig von der Valkey-Redis-Debatte als Performance-Alternativen bestehen. Dragonfly zielt auf extreme Single-Node-Performance mit einer Multi-Thread-Shared-Nothing-Architektur, KeyDB auf Multi-Threading im Redis-Codebase. Für Teams mit sehr spezifischen Latenz-Anforderungen bleiben beide relevante Optionen – für den Standard-Cache-Use-Case ist Valkey 9 die pragmatischere Wahl, weil die Managed-Service-Unterstützung der Hyperscaler fehlt.

Ist die AGPLv3 von Redis 8 ein Problem für den internen Einsatz?

In den meisten Fällen nein. Die AGPLv3-Viralität greift, wenn der modifizierte Code als Netzwerk-Service an Dritte weitergegeben wird. Klassischer interner Cache-Einsatz – Anwendung ruft Redis über das Netzwerk auf, ohne Redis-Code zu modifizieren – ist AGPLv3-neutral. Wer unsicher ist, sollte dennoch die Rechtsabteilung einbeziehen, insbesondere bei SaaS-Produkten, die Redis-basierte Funktionen nach außen exponieren.

Unterstützt Google Memorystore Valkey 9 bereits produktiv?

Ja. Memorystore for Valkey 9.0 ist laut Google Cloud Blog seit dem Release im Oktober 2025 GA und wird aktiv als Upgrade-Pfad von älteren Memorystore-Redis-Instanzen angeboten. AWS ElastiCache und Oracle OCI Cache ziehen parallel nach. Für Frankfurt-Regionen bedeutet das: Wer heute einen neuen Cluster provisioniert, bekommt Valkey 9 ohne Zusatzkonfiguration.

Was ändert sich bei Monitoring und Alerting, wenn ich auf Valkey migriere?

Die wichtigsten Metriken des INFO-Commands bleiben kompatibel, sodass Standard-Dashboards von Datadog, Grafana und New Relic ohne Änderungen funktionieren. Valkey ergänzt zusätzliche Felder für die neuen Features (I/O-Threading-Statistiken, atomare Slot-Migration-Status), die in bestehenden Dashboards ignoriert werden. Wer eigene Parser oder Prometheus-Exporter baut, sollte die INFO-Ausgabe einmal gegen Valkey 9 testen und bei Bedarf die neuen Felder in die Panels aufnehmen.

Mehr aus dem MBF Media Netzwerk

• Managed Services: Warum der Mittelstand IT auslagert statt aufbaut (MyBusinessFuture)
• KI-Governance 2026: Nur 14 Prozent haben geklärt, wer die Verantwortung trägt (Digital Chiefs)
• E-Mail-Authentifizierung: SPF, DKIM und DMARC richtig konfigurieren (SecurityToday)

Quelle Titelbild: Pexels / Mikhail Nilov