Valkey vs Redis 2026: Solltest du dein SaaS von Redis migrieren?
Die Frage Valkey vs Redis begann 2024 als Lizenzstreit und ist inzwischen still zu einer gewöhnlichen Infrastrukturentscheidung geworden. Redis wechselte weg von BSD, ein Fork der Linux Foundation erschien mit Rückendeckung von AWS, Google, Oracle, Ericsson und Snap, und etwa ein Jahr lang drehte sich die Diskussion vor allem um Prinzipien. Zwei Jahre später haben beide Projekte mehrere Major-Versionen ausgeliefert, Redis hat AGPLv3 wieder in seine Lizenzoptionen aufgenommen, und die Managed-Angebote sind beim Preis auseinandergelaufen. Die Entscheidung steht jetzt auf viel nüchternerem Boden: Kosten, Feature-Fit und wie viel operatives Risiko eine Migration für dein Team tatsächlich trägt.
Die meisten Teams, mit denen wir sprechen, nutzen Redis für drei Dinge: Session-Speicher, Cache und eine Job-Queue hinter Symfony Messenger oder BullMQ. Für diesen Workload lautet die ehrliche Antwort, dass beide Engines funktionieren und der entscheidende Faktor selten technisch ist. Dieser Beitrag zeigt, was sich geändert hat, was nicht, und ein Entscheidungsframework, das du an einem Nachmittag anwenden kannst statt in einem Quartal.
Was sich an der Redis-Lizenz wirklich geändert hat
Im März 2024 wechselte Redis von der BSD-3-Clause-Lizenz zu einer dualen RSALv2- und SSPLv1-Konstruktion. Das praktische Ziel dieser Änderung waren Cloud-Anbieter, die Redis als Managed Service weiterverkaufen. Die Linux Foundation forkte das letzte BSD-lizenzierte Release innerhalb von Wochen zu Valkey, und die großen Cloud-Anbieter verlagerten ihre Engineering-Kapazität dorthin.
Im Mai 2025 fügte Redis dann ab Redis 8 AGPLv3 als dritte Lizenzoption hinzu. Das ist relevant, denn AGPLv3 ist eine OSI-anerkannte Open-Source-Lizenz, womit das Framing "Redis ist kein Open Source mehr" nicht mehr zutraf. Was AGPLv3 verlangt, ist die Offenlegung des Quellcodes für modifizierte Versionen, die über ein Netzwerk erreichbar sind. Wenn du Stock-Redis als Cache hinter deiner Anwendung betreibst, berührt diese Pflicht deinen Anwendungscode nicht. Wenn du Redis forkst, patchst und den gepatchten Build als Netzwerkdienst anbietest, schuldest du deinen Nutzern diese Änderungen.
Das ist der am häufigsten missverstandene Punkt in der Valkey-vs-Redis-Debatte, deshalb sei er klar ausgesprochen: Für ein typisches B2B-SaaS, das eine Managed-Redis-Instanz von AWS, Google Cloud oder einem europäischen Hoster betreibt und nichts Exotischeres tut als SET, GET und ein oder zwei Lua-Skripte, hatte die Lizenzänderung keine rechtliche Konsequenz. Niemand muss aus Compliance-Gründen migrieren. Eine echte Exposition haben Teams, die eine Cache-Engine in ein distribuiertes Produkt einbetten, auf einem gepatchten Fork aufbauen oder unter einer Beschaffungsrichtlinie arbeiten, die Copyleft-Lizenzen im Dependency-Tree pauschal ablehnt. Dieser letzte Fall ist in Enterprise- und Public-Sector-Deals häufiger, als Engineers erwarten, und er ist ein legitimer Grund, BSD zu bevorzugen.
Valkey vs Redis: Wo die Feature-Parität steht
Valkey startete als Fork von Redis 7.2.4, daher sind Kern-Command-Set, Datentypen und Client-Protokoll identisch. Jede gängige Client-Bibliothek spricht ohne Änderung mit beiden. Seitdem sind die beiden Projekte unterschiedliche Wege gegangen.
Valkey steckte seine frühe Arbeit in Durchsatz und Replikation. Version 8 führte asynchrones I/O-Threading und Dual-Channel-Replikation ein, die den RDB-Snapshot-Transfer vom laufenden Replikationsstream trennt und Full-Sync-Fenster bei großen Datenmengen deutlich verkürzt. Version 9, 2025 erschienen und durch 2026 hindurch iteriert, ergänzte atomare Slot-Migration für Cluster-Resharding sowie BSD-lizenzierte Pendants für JSON, Bloom-Filter und Vektorsuche als Module statt Kernfeatures. Aktuelle 9.x-Benchmarks liegen bei niedrigen Millionen Requests pro Sekunde auf Standard-Hardware, moderat vor vergleichbaren Redis-Builds bei cache-lastigen Workloads.
Redis ging stattdessen in die Breite. Redis 8 holte die früheren Redis-Stack-Module in den Kern: JSON, Time Series, probabilistische Strukturen und die Query Engine sind jetzt Teil der Standard-Distribution, dazu Vector Sets als vollwertiger Datentyp. Redis 8.2 kam Anfang 2026 mit Verbesserungen am Client-Side-Caching-Protokoll und besseren Optionen für Vektorähnlichkeit. Wenn du Redis als Suchmaschine, Time-Series-Store oder Vektordatenbank nutzt, liegt Redis weiterhin vorn, und der Abstand ist real, nicht kosmetisch.
Die Paritätsfrage löst sich damit sauber auf. Ist Redis für dich ein Cache, ein Session-Store, ein Rate Limiter, ein Lock oder ein Queue-Backend, ist Valkey ein Drop-in-Ersatz, und du wirst den Unterschied nicht bemerken. Macht Redis in deinem Stack Volltextsuche oder Time-Series-Arbeit, deckt Valkey dich noch nicht ab.
Das operative Risiko einer Migration
Eine Valkey-Migration ist keine Datenbankmigration, und sie wie eine zu behandeln ist die häufigste Quelle der Überschätzung. Es gibt kein Schema, kein ORM-Mapping und in den meisten Fällen keine Änderung am Anwendungscode. Die Client-Bibliothek bleibt dieselbe. Der Connection-String zeigt woandershin.
Wofür du planen musst, sind die Daten selbst. Die Persistenzformate von Redis sind seit dem Fork auseinandergelaufen, eine von Redis 8 geschriebene RDB-Datei lädt also nicht garantiert in Valkey 9. Die zuverlässigen Wege sind ein replikationsbasierter Cutover, bei dem du Valkey als Replica deines bestehenden Redis-Primary anhängst und in einem kurzen Wartungsfenster promotest, oder ein Kaltstart, bei dem du einen leeren Cache akzeptierst und ihn sich wieder füllen lässt. Für einen reinen Cache ist der Kaltstart meist in Ordnung und braucht zehn Minuten Planung. Für Session-Speicher replizierst du entweder, oder du loggst alle aus, und nur eines davon ist an einem Dienstagmorgen akzeptabel.
Das andere, was du prüfen solltest, ist alles Modulförmige. RediSearch, RedisJSON, RedisTimeSeries und RedisBloom haben Valkey-Pendants mit überlappenden, aber nicht identischen APIs, und ein naiver Tausch bricht die Query-Syntax. Greppe deine Codebasis nach FT.-, JSON.- und TS.-Commands, bevor du irgendwem eine Zwei-Stunden-Migration versprichst. Genau die Art von Ding, die ein kurzes Code- und Dependency-Review in einer Stunde aufdeckt und ein überhasteter Cutover um 3 Uhr nachts entdeckt.
Konfigurationshinweise für Symfony und Next.js
Auf der Symfony-Seite verbinden sich sowohl predis/predis als auch die phpredis-Extension ohne Änderungen mit Valkey, weil das Wire-Protokoll dasselbe ist. Cache- und Session-Konfiguration in framework.yaml brauchen nur einen neuen DSN, und der Redis-Transport von Symfony Messenger funktioniert unverändert gegen Valkey. Wenn du Redis Sentinel betreibst, beachte, dass Valkeys Sentinel-Pendant kompatibel ist, die Binary-Namen sich aber in manchen Distributionen unterscheiden. Deine Health-Checks und systemd-Units brauchen also womöglich Anpassungen, obwohl deine Anwendung keine braucht.
Auf der Next.js-Seite funktionieren ioredis und node-redis beide, und BullMQ läuft bei vielen Teams produktiv auf Valkey. Genau hinschauen solltest du nur bei Code, der von einem Redis-8-spezifischen Feature abhängt, insbesondere Vector Sets oder der Query Engine, für die es kein direktes Valkey-Pendant gibt. Nutzt deine Next.js-App Redis nur für ISR-Cache-Tags, Rate Limiting oder einen Session-Store, gibt es jenseits der Konfiguration nichts zu ändern.
In welche Richtung du auch gehst, halte die Engine-Wahl hinter einer dünnen Abstraktion in deinem eigenen Code. Nicht weil du planst, nochmal zu wechseln, sondern weil die Teams mit einer schmerzfreien Migration 2026 diejenigen waren, die rohe Client-Aufrufe nicht über vierzig Dateien verstreut hatten. Das ist dieselbe Disziplin, die ein Legacy-Modernisierungsprojekt Jahre später handhabbar macht.
Der Kostenfall, der meist der eigentliche Fall ist
Beim Preis wird die Entscheidung konkret. AWS hat ElastiCache für Valkey beim Node-basierten Pricing rund 20 Prozent unter Redis OSS positioniert und bei Serverless eher ein Drittel darunter, und Database Savings Plans stapeln weitere Rabatte obendrauf. Google Memorystore, Aiven und Upstash bieten alle Valkey-Tiers mit ähnlicher Positionierung. Für ein Team, das 200 Euro im Monat für Cache ausgibt, ist das ein Rundungsfehler. Für ein Team mit 4.000 Euro im Monat über mehrere Umgebungen ist es ein echter Posten, der für immer wiederkehrt.
Diese Asymmetrie ergibt eine einfache Regel. Die Migration kostet dich eine fixe Menge Engineering-Zeit, irgendwo zwischen einem halben Tag und zwei Wochen, je nachdem, wie viele Module du nutzt und ob du einen replikationsbasierten Cutover brauchst. Die Ersparnis kehrt monatlich wieder. Teile das eine durch das andere und du bekommst eine Amortisationszeit. Liegt sie unter sechs Monaten, migriere. Liegt sie über zwei Jahren, verschwende keine Meeting-Zeit darauf.
Ein Entscheidungsframework, das du heute anwenden kannst
Gehe die Punkte der Reihe nach durch und stoppe bei der ersten klaren Antwort.
Migriere zu Valkey, wenn einer dieser Punkte zutrifft: Dein Beschaffungs- oder Rechtsteam hat eine Richtlinie gegen Copyleft-Lizenzen in Produktions-Dependencies, deine Managed-Cache-Rechnung ist groß genug, dass eine Reduktion um 20 bis 30 Prozent eine Amortisationszeit unter einem Jahr hat, du bist bereits auf AWS und nutzt ElastiCache, wo Valkey inzwischen die empfohlene Standard-Engine ist, oder du baust neue Infrastruktur auf und hast gar keine Migrationskosten. Dieser letzte Fall ist die einfachste Entscheidung in diesem ganzen Beitrag: Für Greenfield-Caching-Workloads nimm standardmäßig Valkey.
Bleib bei Redis, wenn einer dieser Punkte zutrifft: Du hängst von der Query Engine, Time Series oder Vector Sets ab, dein Cache-Budget ist klein genug, dass die Ersparnis das Change-Fenster nicht rechtfertigt, dein Team hat dieses Quartal keine Kapazität für Infrastrukturarbeit, oder du hast einen Redis-Enterprise-Vertrag mit Support-Konditionen, die du tatsächlich nutzt.
Tu nichts, wenn keine der Listen eine klare Antwort liefert. Eine Cache-Engine, über die du nicht nachdenkst, ist eine Cache-Engine, die funktioniert, und "wir könnten 40 Euro im Monat sparen" ist keine Strategie. Schau wieder drauf, wenn du das nächste Mal Hosting neu verhandelst oder etwas Angrenzendes replatformst.
Wo Wolf-Tech reinpasst
Wir helfen SaaS-Teams, diese Art von Entscheidung zu treffen, ohne sie zu einer quartalslangen Evaluierung aufzublasen. In der Praxis heißt das meist: eine Session, um zu erfassen, was dein Cache wirklich tut, ein Blick darauf, ob Modul-Abhängigkeiten brechen würden, und ein Cutover-Plan, der auf das Risiko dimensioniert ist statt auf den Hype. Manchmal lautet die Empfehlung, nächsten Sprint zu migrieren. Öfter lautet sie, es in Ruhe zu lassen und die Woche in etwas zu stecken, das das Produkt voranbringt, und das ist ein völlig gutes Ergebnis für ein Infrastruktur-Review.
Wenn du diese Entscheidung abwägst oder eine größere Tech-Stack-Strategie-Frage dahinter liegt, schreib uns an hello@wolf-tech.io oder besuche wolf-tech.io. Wir schauen uns dein Setup gern an und sagen dir klar, ob die Migration die Zeit deines Teams wert ist.