Valkey: de beste open-source drop-in vervanger voor Redis


In maart 2024 stapte Redis Inc. over van een permissieve BSD-licentie naar RSALv2/SSPLv1, wat echte risico's op gebied van naleving creëerde voor commerciële engineeringteams.

Als reactie hierop splitste de OSS- en gebruikersgemeenschap Redis vrijwel onmiddellijk af in een nieuwe optie met de naam Valkey. Valkey, gelanceerd in dezelfde maand onder de Linux Foundation, biedt een echte drop-in vervanger die de juridische ballast van Redis omzeilt.
OVHcloud_Cloud_Database_Business_600x400@2x.png

Vervang Redis zonder uw apps opnieuw te bouwen

Redis heeft zijn reputatie als de go-to in-memory datastore met goede reden opgebouwd. Het is snel, flexibel en (was) oprecht open. Maar een reeks licentiebesluiten sinds maart 2024 heeft engineering- en juridische teams gedwongen hun blootstelling opnieuw te evalueren en te zoeken naar een cache-alternatief. 

De reactie van gemeenschappen op de licentiewijzigingen van Redis was om te zoeken naar snelle, gecoördineerde en goed gefinancierde opties, voornamelijk een een afsplitsing van de gemeenschappen. Valkey is geen protest fork met weinig ondersteuning. Valkey profiteert van substantiële institutionele steun en begeleiding en actieve ontwikkeling – dus het is een volledig BSD-gelicentieerd alternatief, volledig compatibel met de Redis-codebase die de meeste teams al gebruiken.
171787e4-7090-45ca-9346-5fafb7c170fe_ima_81ddb684.png

Valkey: Geruststelling ingebouwd in het project en de service

Open governance, compatibiliteit, beheerde resilience en vertrouwde fundamenten
[object Object]
Door de gemeenschap gedreven
[object Object]
Drop-in compatibiliteit
[object Object]
Beheerde resilience
[object Object]
Vertrouwde fundamenten

Waarom ontwikkelaars in 2026 op zoek zijn naar een Redis-alternatief

De Redis-licentiewijziging van 2024 uitgelegd

Het grootste deel van zijn bestaan werd Redis gedistribueerd onder de BSD 3-Clause-licentie, een van de meest permissieve open-sourcelicenties. Men kon Redis zonder beperkingen gebruiken, aanpassen en er commerciële producten op bouwen. Dat veranderde op 20 maart 2024, toen Redis Inc. aankondigde dat Redis 7.4 en alle toekomstige feature-releases zouden overstappen op een dubbel licentiemodel: RSALv2 (Redis Source Available License v2) en SSPLv1 (Server Side Public License). Geen van beide licenties is goedgekeurd door het Open Source Initiative (OSI), en beide leggen expliciete beperkingen op aan hoe de software in commerciële en cloudomgevingen kan worden gebruikt.

Waarom SSPL een nalevingsrisico vormt voor commerciële producten

SSPL werd oorspronkelijk geschreven door MongoDB om te voorkomen dat cloudproviders beheerde databaseservices aanbieden zonder iets terug te geven. Het kernprobleem voor commerciële productteams is paragraaf 13: als uw applicatie als een dienst beschikbaar wordt gesteld en deze afhankelijk is van software met een SSPL-licentie, kunt u verplicht worden om de broncode van uw gehele servicestack vrij te geven, inclusief eigen componenten die u hebt ontwikkeld.

Voor de meeste engineeringteams is die verplichting onbespreekbaar bij het ontwikkelen van functies en alternatieven. Zelfs waar juridisch adviseurs bepalen dat het risico in de praktijk laag is, creëert de onzekerheid alleen al wrijving bij inkoop, beveiligingsbeoordelingen en contracten met zakelijke klanten. RSALv2 verergert dit door het gebruik in concurrerende producten of functies expliciet te verbieden, waardoor Redis Inc. brede discretie krijgt over wat concurrentie vormt... wat Redis-gebruikers opnieuw blootstelt aan een juridisch mijnenveld van juridische uitdagingen – uitdagingen die gemakkelijk worden omzeild door in plaats daarvan code te gebruiken die wordt beheerd door een OSI-goedgekeurde licentie.

Op Redis 7.2 blijven: het verborgen gebrek aan beveiliging

De laatste Redis-cachingrelease onder BSD was versie 7.2. Sommige teams kiezen ervoor om op die versie te blijven, in plaats van de nieuwe licentievoorwaarden te accepteren. Het is wellicht een pragmatische beslissing op korte termijn die kosten op lange termijn met zich meebrengt. Redis 7.2 ontvangt geen beveiligingspatches of bugfixes meer van Redis Inc., wat betekent dat alle CVE's die na de licentiewijziging worden ontdekt, op die branche onbehandeld blijven. Voor teams die Redis 7.2 caching draaien in een productieomgeving, die gevoelige gegevens verwerken of werken onder kaders zoals NIS2 of SOC 2, is dit geen theoretisch risico. Bij Redis 7.2 blijven zorgt voor een actief compliance-kloof dat elke maand groter wordt.

Waarom AGPLv3 voor Redis 8.0 geen derde optie is

Met de release van Redis 8.0 in 2025 maakte Redis Inc. opnieuw een licentie-overstap, ditmaal naar AGPLv3, wat OSI-goedgekeurd is. Het is een echte stap vooruit wat betreft open-source legitimiteit, en het adresseert een van de kernkritiekpunten op de wijziging van 2024. AGPLv3 is echter een sterke copyleft-licentie en introduceert zijn eigen complicaties voor commerciële teams.

Elke software die via een netwerk dialogeert met een component met een AGPLv3-licentie, kan een verplichting activeren om de broncode van die software onder dezelfde licentie vrij te geven. Voor beschermde SaaS-producten blijft dit een aanzienlijke beperking voor alternatieven. Verschillende prominente stemmen in de sector, waaronder bijdragers aan het Valkey-project, hebben opgemerkt dat AGPLv3 (hoewel principiëler dan SSPL) Redis nog steeds in een andere categorie plaatst dan echt permissieve open-source alternatieven.

Preserve app-gedrag en beheer datalocatie

BSDRESP2Clustering
Sinds de oprichting kwalificeert Valkey zich als een drop-in vervanger omdat de compatibiliteit zich uitstrekt over het Redis-protocol, commando's, bibliotheken van klanten, persistentie en clustering. Voor een ondersteunde applicatie kan deze dekking codewijzigingen verminderen en teams in staat stellen te beginnen met validatie met hetzelfde toegangsmodel. 

Multi-node lay-outs kunnen ook vertrouwde patronen qua resilience behouden. Compatibiliteit vereist nog steeds testen. Modules, versie-specifiek gedrag en ongebruikelijke commando-combinaties kunnen een ander antwoord opleveren. Opslagontwerp, klantinstellingen en topologie kunnen ook de stabiliteit of doorvoer beïnvloeden. Bij geen enkele migratie mag ervan worden uitgegaan dat elk grensgeval sneller zal draaien of zich identiek zal gedragen. De door de OSI goedgekeurde licentie van Valkey biedt commerciële teams een duurzaam open-source alternatief voor Redis zonder de applicatiearchitectuur aan beperkende voorwaarden te binden. 

De keuze voor implementatie voegt vervolgens een operationele dimensie toe. Een beheerd Europees aanbod kan threaded verwerking, resilient node-plaatsing en gecontroleerde datahosting combineren. Deze aanpak ondersteunt de Europese datasouvereiniteit door locatie, toegang en contractuele afhandeling zichtbaar te houden en tegelijkertijd het routinematige platformbeheer te verminderen.

2c541d44-5950-4028-b9eb-d3e5efacab26_ima_180e373b.png
Tot de oprichtende bijdragers van Valkey behoren de grootste cloudleveranciers en techbedrijven ter wereld - inclusief databasegiganten. Samen bestrijken zij het merendeel van de wereldwijde cloudinfrastructuur, en dit is geen passieve steunbetuiging. Deze organisaties hebben actieve engineers die bijdragen aan de codebase. Het is gebruikelijk om te zien dat grote cloudleveranciers Redis vervangen door Valkey als standaard voor hun functies. De breedte van de ondersteuning betekent dat Valkey beschikt over de engineering-resources, de capaciteit voor beveiligingsrespons en de toewijding aan een langetermijnroadmap die een onafhankelijke community-fork zelden bereikt.

Valkey is voortgekomen uit de Redis 7.2-codebase, dus de API, commando's, klanten en persistentieformaten bieden een vertrouwde technische basis. Veel applicaties kunnen gevestigde toegangspatronen behouden, maar compatibiliteit hangt af van de exacte versie en configuratie die is geselecteerd. Testscripts, transacties, pub/sub-gedrag, clusteroperaties en ongebruikelijke commando's met representatief applicatieverkeer. Consistentieverwachtingen vereisen ook aandacht. Bevestig het replica-gedrag, de afhandeling van failovers en de leessemantiek in elke bedrijfsmodus. Documentatie en ondersteuningsmatrixen kunnen het onderzoek beperken, terwijl applicatietesten bepalen of de gekozen optie gereed is voor productie.

In onafhankelijke benchmarks houdt Valkey zich goed staande tegenover Redis bij standaard workloads. Eén hyperscale-benchmark vergeleek Valkey 8.1 met Redis 8.2 in 50 miljoen sorted set-items.

DragonflyDB is in sommige testen leidend wat betreft ruwe single-node doorvoer, maar dat voordeel neemt aanzienlijk af in clusterconfiguraties. Feature-pariteit met Redis 7.2 is compleet en de roadmap van Valkey heeft sindsdien verbeteringen in multi-threading en efficiëntiewinsten in geheugengebruik toegevoegd, waardoor het in sommige workloads voorloopt op de versie waarvan het is afgesplitst.

DragonflyDB kan aantrekkelijk zijn voor teams die een moderne architectuur verkennen voor hoge doorvoer, verticale schaling of geheugenefficiëntie. Dragonfly gebruikt echter een ander intern ontwerp en architecturale verschillen kunnen van invloed zijn op clustering, persistentie, operationele tooling en consistentie. Deze factoren kunnen het een minder directe vervanging maken voor sommige bestaande omgevingen. 

Andere technologieën kunnen geschikt zijn voor gespecialiseerde vereisten, zoals vectorzoekopdrachten of intermitterende serverless workloads. Onderzoek kan technisch materiaal omvatten dat is gevonden via Google, discussiesfora en leveranciersdocumentatie, maar primaire documentatie en gecontroleerde testen moeten zwaarder wegen. Vergelijk elk alternatief op basis van applicatiewijziging, operationele volwassenheid, beschikbare ondersteuning, governance en totale migratie-inspanning. De juiste technologie is degene die voldoet aan de gemeten vereisten met acceptabele licentie- en operationele risico's.
Tot de oprichtende bijdragers van Valkey behoren de grootste cloudleveranciers en techbedrijven ter wereld - inclusief databasegiganten. Samen bestrijken zij het merendeel van de wereldwijde cloudinfrastructuur, en dit is geen passieve steunbetuiging. Deze organisaties hebben actieve engineers die bijdragen aan de codebase. Het is gebruikelijk om te zien dat grote cloudleveranciers Redis vervangen door Valkey als standaard voor hun functies. De breedte van de ondersteuning betekent dat Valkey beschikt over de engineering-resources, de capaciteit voor beveiligingsrespons en de toewijding aan een langetermijnroadmap die een onafhankelijke community-fork zelden bereikt.

Stem het bedrijfsmodel af op uw vereisten

Beheerde Valkey

Managed Databases for Valkey is geschikt voor bedrijven die eenvoudige operaties en voorspelbare infrastructuurkosten willen. OVHcloud beheert hoge beschikbaarheid, onderhoud, monitoring en back-ups, waardoor het interne werk dat nodig is om een resiliente dienst te draaien, wordt verminderd. Inbegrepen bandbreedte en IOPS maken budgettering ook duidelijker. Dit is een praktische standaard wanneer platformteams Valkey nodig hebben zonder elke operationele taak zelf te hoeven uitvoeren.

Zelfbeheerde Valkey

Zelfbeheer biedt controle over softwareversies, topologie, beveiligingsinstellingen en implementatielocatie. Het kan passen bij bedrijven met specifieke vereisten of gevestigde databaseactiviteiten. De nadelen zijn even reëel: het interne team is verantwoordelijk voor upgrades, back-ups, waarneembaarheid, failover-testen en incidentrespons. Communitybronnen helpen, maar ze vervangen geen verantwoorde productieondersteuning of operationele capaciteit.

KeyDB

KeyDB kan geschikt zijn voor teams die multithreaded uitvoering onderzoeken voor specifieke geheugendata-workloads en latentiedoelen. Evalueer compatibiliteit, release-activiteit, projectgezondheid en beschikbare ondersteuning voordat u zich vastlegt. Benchmark de daadwerkelijke applicatie in plaats van aan te nemen dat een architecturale functie elk verzoekpatroon zal verbeteren. Informatie die geassocieerd wordt met een oprichter of een vroege projectverklaring moet ook worden gecontroleerd aan de hand van de huidige documentatie.

Gespecialiseerde alternatieven

Serverless diensten kunnen capaciteitsplanning voor intermitterende workloads verminderen, terwijl vectordatabases zoekopdrachten naar overeenkomsten en andere gespecialiseerde datamodellen ondersteunen. Alternatieve in-memory software kan zich richten op specifieke doorvoer- of persistentiebehoeften. Deze tools kunnen gedefinieerde problemen oplossen, maar het zijn niet noodzakelijkerwijs drop-in keuzes. Houd rekening met applicatiewijzigingen, gegevensverplaatsing, operationeel eigenaarschap en langetermijnkosten voordat u ze verkiest boven Valkey.

Kies een migratiepad dat past bij de downtime

RDBAOFRESP2
Er zijn twee praktische benaderingen voor het migreren van Redis naar Valkey. De juiste hangt af van of u een onderhoudsvenster kunt tolereren. De dump/restore-methode is de juiste aanpak voor kleinere datasets of niet-kritieke omgevingen. Omdat Valkey hetzelfde RDB-snapshotformaat gebruikt als Redis, kunt u een dump.rdb-bestand exporteren vanuit uw Redis-instance en dit direct in Valkey laden zonder conversiestap.

Sluit uw Redis-instance af voor consistentie, kopieer het bestand naar uw Valkey-datamap, start Valkey en u bent klaar. De totale migratietijd is evenredig aan de grootte van de dataset, niet aan de complexiteit van de applicatie. Voor productieomgevingen waar downtime niet acceptabel is, is live replicatie een veiliger pad. Valkey kan worden geconfigureerd als een replica van een draaiende Redis 7.2-instance met behulp van het standaard REPLICAOF-commando.

Zodra de replica volledig is gesynchroniseerd, werkt u de verbindingsreeks van uw applicatie bij om naar Valkey te wijzen, stelt u deze in als primair en stelt u de Redis-instance buiten gebruik. Omdat beide systemen hetzelfde replicatieprotocol spreken, is dit proces duidelijk en uitgebreid getest in productie door teams bij alle grote cloudproviders.
[object Object]

Bouw een vierdelig framework voor migratiegereedheid

1. Applicatiecompatibiliteit

Maak een inventarisatie van elk commando, elke klantbibliotheek en elke protocolversie die in gebruik is. Leg RESP3-functies, Lua-scripts, transacties, pub/sub-patronen, JSON- of module-afhankelijkheden en applicatiespecifiek time-outgedrag vast. Een compatibele kern bewijst niet dat elke extensie op dezelfde manier reageert. Vergelijk de huidige omgeving met de doelversie en test representatieve verzoeken. Neem foutafhandeling, connection pooling en retry-logica op. Als een applicatie afhankelijk is van technologie die door een externe plug-in wordt geleverd, controleer dan de onderhoudsstatus afzonderlijk. Deze inventarisatie verandert algemene compatibiliteit in bewijs op basis van specifieke vereisten.

2. Bescherm de gegevensintegriteit

Meet de dataset vóór de migratie, inclusief het aantal sleutels, de verdeling van vervaltijden, objectgroottes en het piekgeheugengebruik. Het doel heeft voldoende geheugen nodig voor normale werking, replicatie en tijdelijke overhead tijdens synchronisatie of persistentie. Controleer instellingen voor snapshots en append-only in plaats van ze zonder analyse te kopiëren. Vergelijk na de overdracht het aantal sleutels, gesamplede waarden en het verloop van vervaltijden. Controles op applicatieniveau kunnen problemen aan het licht brengen die onbewerkte totalen missen, zoals misvormde sessies of een onvolledige wachtrijstatus. Deel acceptatiecriteria met service-eigenaren vóór de overschakeling, zodat iedereen dezelfde definitie van een geldige dataset hanteert.

3. Breng de doeltopologie in kaart

Documenteer of het huidige platform standalone is, gerepliceerd is of verspreid over een cluster. Registreer elk knooppunt, netwerkroute, beveiligingsregel, DNS-afhankelijkheid en fysieke locatie. Deze kaart helpt teams bij het selecteren van een doellay-out die de behoeften aan resilience weerspiegelt in plaats van historische keuzes te reproduceren. Connectiviteitstesten moeten de applicatie, monitoringsystemen en beheertools dekken. Verifieer voor een gedistribueerde workload de slot-afhandeling, replica-plaatsing en het gedrag tijdens knooppuntverlies. Vereisten voor datalocatie kunnen ook bepalen welke regio's of beschikbaarheidszones acceptabel zijn.

4. Beheers de omschakeling

Stel latentie-, foutpercentage- en resource-baselines vast voordat u verkeer verplaatst. Definieer monitoringdrempels, rollback-criteria en beslissingsbevoegden terwijl de dienst stabiel is. Dit voorkomt dat teams discussiëren over acceptabel gedrag tijdens een incident. Verplaats verkeer in fasen waar de architectuur dit toelaat. Begin met interne of risicoarme workloads, observeer fouten van klanten en vergelijk resultaten, en verhoog daarna het aandeel. Houd de bron herstelbaar totdat de validatie is voltooid. Een veilige omschakeling hangt af van gemeten bewijs, duidelijk eigenaarschap en een rollback-route, niet alleen van compatibiliteitsclaims.

Waarom kiezen voor OVHcloud Managed Databases for Valkey

Valkey draaien in productie is één beslissing. Beslissen hoe u het beheert voor stabiliteit is een andere. Het zelf beheren van een in-memory cluster, inclusief het afhandelen van replicatie, failover, patching en back-ups, voegt operationele overhead toe die slecht schaalt naarmate uw team en dataset groeien. OVHcloud Managed Databases for Valkey neemt die last volledig weg, met een volledig beheerde dienst die is opgebouwd rond drie zaken waar Europese engineeringteams consequent behoefte aan hebben: resilience, kostenvoorspelbaarheid en gegevenssoevereiniteit.

Een van de aanhoudende frustraties bij cloud-beheerde databases is de onvoorspelbaarheid van de factuur. Denk aan kosten die onder belasting de pan uit rijzen omdat bandbreedte, IOPS en back-upopslag afzonderlijk worden gemeten. Het prijsmodel van OVHcloud bundelt deze kosten in een vast maandtarief. Bandbreedte, I/O-operaties en geautomatiseerde back-ups zijn inbegrepen, dus de kosten die u ziet bij het inrichten zijn de kosten die u betaalt in productie. Voor financiële en inkoopteams in scale-ups die krappe infrastructuurbudgetten beheren, maakt dit capaciteitsplanning aanzienlijk overzichtelijker.
OVHcloud_Baremetal_600x400.png
Blik op de toekomst – OSS-licenties in de gaten houden
De Redis-licentiesituatie is geen op zichzelf staand incident in het landschap van open-source licenties. Naarmate open-source projecten volgroeien en de bedrijven erachter belangrijke aspecten proberen te gelde te maken, zijn licentiewijzigingen een steeds vaker voorkomend pijnpunt geworden voor engineeringteams. De basis begrijpen van hoe open-source licenties werken en waar men op moet letten, is nu een noodzakelijke vaardigheid voor iedereen die verantwoordelijk is voor een productietechnologiestack.
Verken Valkey