Hoewel in-memory caching-engines voor velen onbekend terrein zijn, zijn ze van kritiek belang voor het accelereren van applicaties. De afgelopen 2,5 jaar hebben twee evolutiepaden getoond, met aan de ene kant Valkey, een fork met steun van enkele van de grootste bedrijven ter wereld, en daartegenover Redis, aangestuurd door het gelijknamige bedrijf. Op ValkeyConf 2026 in Praag brachten we in kaart hoe Valkey zich in een gestaag tempo blijft aanpassen aan zijn omgeving met steeds iets andere trekjes dan de voorvader had.
Valkey is een direct gevolg van het besluit van Redis om in maart 2024 zijn open source-licentie los te laten. In mei 2025 kwam Redis daar deels op terug door AGPLv3 toe te voegen als een van drie licentieopties. Valkey, met steun van onder meer AWS, Google Cloud en Oracle, is daarentegen een fork onder BSD-licentie die met versie 7.2.5 een drop-in-vervanger voor Redis 7.2.4 bood. Sindsdien zijn de twee geleidelijk uit elkaar gegroeid. Redis wil de context engine voor AI-agents worden en wil zich profileren als een volwaardig dataplatform. Valkey blijft intussen een gespecialiseerde tool en wordt, anders dan Redis, niet bestuurd door één vendor, maar door een collectief van maintainers met gedeelde belangen.
Valkey core is enkel een in-memory key-value store. Het houdt data in het RAM-geheugen, zodat applicaties er ruim binnen een milliseconde bij kunnen. Die data is georganiseerd in datastructuren zoals strings, hashes, lists, sets en sorted sets, in plaats van in rijen en tabellen. Dat is doorgaans ongeveer een orde van grootte sneller dan het opzoeken van data in een database, wat meestal enkele milliseconden duurt. Omdat geheugen eindig is (en duur!), is het cruciaal om goed te kiezen wat je cachet en de beschikbare capaciteit optimaal te benutten. Elke cloudprovider en elke organisatie met aandacht voor de portemonnee loopt tegen dat probleem aan, terwijl een eigen, propriëtaire oplossing die je vervolgens zelf moet onderhouden weinig oplevert. Veel IT-teams werken met Valkey via ElastiCache of MemoryDB op AWS, Memorystore for Valkey op Google Cloud, OCI Cache in de cloud van Oracle, of Valkey managed onder weer een andere naam bij een andere provider.
“Iedereen heeft een caching-engine nodig. Maar de meeste mensen kiezen niet op basis van de caching-engine waar ze hun applicaties of databases draaien”, zegt Kyle Davis, General Manager Redis-Valkey Ecosystem bij Percona.
Niet twee keer hetzelfde bouwen
“Het is niet logisch dat drie onafhankelijke bedrijven precies hetzelfde bouwen voor wat grotendeels een opgelost dataplane-probleem is”, zegt Madelyn Olson, Principal Engineer bij AWS, medeoprichter en maintainer van Valkey. “Het is logischer om gewoon samen aan één ding te werken en dat goed te maken voor onze eindgebruikers.”
Olson doelt daarmee specifiek op vector similarity search, de techniek waarmee AI-toepassingen de opgeslagen informatie vinden die qua betekenis het dichtst bij een zoekopdracht ligt. Verschillende cloudproviders bouwden die los van elkaar. AWS voegde de functie in november 2023 als preview toe aan MemoryDB for Redis; Google maakte dezelfde feature in april 2024 algemeen beschikbaar voor Memorystore for Redis. Later doneerde Google zijn vector search aan Valkey, waar die uitgroeide tot de valkey-search-module onder BSD-licentie. AWS baseert de vector search in ElastiCache inmiddels op diezelfde module.
Concurreren op de engine zelf loont kennelijk niet. Nog een voorbeeld: bij gebrek aan een officiële Kubernetes-operator voor Valkey verwezen handleidingen eind 2024 naar opties van derden, terwijl bedrijven als SAP en Inditex hun eigen operators publiceerden. De officiële valkey-io-operator, die volgens het project bijna algemeen beschikbaar is, moet de gemeenschappelijke basis worden. Voor authenticatie gebeurt iets vergelijkbaars. Oracle bouwde een eigen authenticatie-extensie als Valkey-module en andere cloudproviders volgden een soortgelijk patroon, zegt Dmitry Polyakovsky, Consulting Member of Technical Staff bij Oracle en Lead Engineer van OCI Cache. Inmiddels wordt er gesproken over een gemeenschappelijke module met plug-ins per leverancier. De meeste bedrijven willen hun eigen aanpassingen niet op lange termijn onderhouden, zegt Olson, en proberen die daarom upstream onder te brengen.
Jacob Murphy, Staff Software Engineer bij Google Cloud, Valkey-maintainer en lid van de Technical Steering Committee (TSC), ziet de waarde in van het op een of andere manier ‘canoniek’ maken van een interne innovatie: “Dat maakt het makkelijk te onderhouden, en iedereen kan ervan profiteren.”
Governance
Organisaties hebben de eigenaardige neiging systemen te bouwen die hun eigen structuur weerspiegelen. Dat staat bekend als de wet van Conway, waar Murphy op het podium van ValkeyConf naar verwees. Valkey is bewust gedecentraliseerd opgezet, met negen maintainers in de TSC die bij verschillende bedrijven werken. Voor wijzigingen in die structuur is een gekwalificeerde meerderheid nodig, terwijl voor grote beslissingen ‘slechts’ vijf van de negen stemmen volstaan. Nieuw is een uitzondering waarbij twee voorstanders voor een voorstel kunnen volstaan als er binnen twee weken geen bezwaar komt. Dat versnelt de voortgang. Zo is ook Valkey zelf decentraal met modules buiten de core die optioneel zijn. Zie hier de overeenkomst tussen governance en architectuur.
Toch geeft Olson grif toe dat het releasetempo van Valkey, gezien de snelheid van AI-innovaties, misschien niet helemaal toereikend is. De halfjaarlijkse releases hebben sommige vendoren ertoe gebracht functies zelf te bouwen voordat die in Valkey worden geïntegreerd, waarbij ze profiteren van de permissieve BSD-licentie. “De community hecht veel meer aan stabiliteit en consistentie [dan aan innovatiesnelheid]”, zegt ze. “Wij doen er aan onze kant dus wat langer over om iets te integreren en voor de lange termijn stabiel te krijgen, terwijl bedrijven individueel heel snel de functionaliteit kunnen bouwen die ze nodig hebben.”
Dat blijft een doorlopend proces. Volgens Polyakovsky verloopt de samenwerking binnen het Valkey-project heel goed. Op de Contributor Summit, de dag na ValkeyConf, wilde hij “bepaalde ideeën die we allemaal los van elkaar hebben geïmplementeerd” voorstellen. Die horen volgens hem in Valkey thuis, “zodat we allemaal kunnen voorkomen dat we onze eigen aangepaste forks moeten onderhouden”.
De grote migratie
Adoptie door gebruikers is weer een ander verhaal. Met de licentiewijziging verspeelde Redis het vertrouwen van veel gebruikers, en vertrouwen komt te voet en gaat te paard. “Redis gold vroeger als een veilige keuze. Nu wordt het gezien als een risico”, zegt Davis, die eerder bij Redis werkte. We willen hier geen standpunt innemen en hopen Redis bij gelegenheid naar zijn kant van het verhaal te vragen. Toch lijkt de conclusie dat Valkey een blijvertje is moeilijk te ontlopen. De vraag is vooral wanneer bedrijven overstappen als ze dat niet al hebben gedaan. Uit gesprekken met bezoekers blijkt dat dat niet altijd zo eenvoudig is als de migratiepaden online doen voorkomen.
Davis wijst erop dat caching vaak de kern van applicaties vormt. Je wilt dan ook niet zomaar sleutelen aan iets wat goed werkt, zelfs als dat grote prestatiewinst oplevert. Valkey zelf is zelden de bottleneck, zegt Davis; klanten klagen niet over de prestaties (en deden ze dat wel, dan is dat prestatieniveau weer aanzienlijk beter). Toch kan migreren lonen voor wie nog op versies uit het Redis 7.2-tijdperk draait. Voor workloads met veel strings mat Percona 37,5 procent minder geheugen per key op Valkey 9.1 dan op versie 7.2, de codebase die Valkey deelde met Redis 7.2.4. In een wereld waarin men stelt dat de DRAM-prijzen tussen begin 2024 en eind 2026 met meer dan 400 procent zijn gestegen, is zo’n winst welkom.
Problemen kunnen bovendien overslaan van het technische naar het regelgevende vlak. “We denken dat het aanpassen van broncode makkelijk is, maar organisatorische dynamiek maakt het ontzettend moeilijk”, zegt Davis. “In een gereguleerde sector maak je een wijziging van vijf regels in de broncode. Die wijziging kost je een halfuur, maar goedkeuring krijgen kost je zes maanden. Dat is overdreven, maar het duurt lang.”
Conclusie: divergentie (én convergentie)
Polyakovsky merkt op dat het lastig is de twee compatibel te houden, omdat de forks onvermijdelijk uit elkaar groeien. Volgens Olson blijven de kernabstracties (het protocol en de API voor eindgebruikers) herkenbaar, ook als alles daaromheen verandert. Het ontstaan van het Valkey-project zelf was uiteindelijk het bewijs dat de doelen van Redis en die van zijn grootste gebruikers en externe maintainers uiteenliepen. Valkey is vooral een convergentie van ideeën: deelnemers concurreren niet op de engine en geen enkel bedrijf is dé eigenaar. “Niemand is tegen geheugenefficiëntie”, vat Murphy het bondig samen. “En niemand is tegen prestatieverbeteringen.”
We mogen dan ook verwachten dat Valkey een verzamelplaats blijft voor de beste ideeën uit de sector rond caching, waar kleine codewijzigingen een onevenredig grote efficiëntiewinst kunnen opleveren. Met de AI-opmars, waarin capaciteitstekorten en door LLM’s gegenereerde code (die meetbaar inefficiënt is) elkaar steeds verder opstuwen, is een focus op maximale utilisatie zeer welkom.