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.

Vervang Redis zonder uw apps opnieuw te bouwen
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.

Valkey: Geruststelling ingebouwd in het project en de service
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
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.

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