Valkey eller Redis? De två nyckel-värde-servrarna jämförda

Det korta svaret

Välj Valkey om du vill ha en cache, sessioner eller jobbköer under en tillåtande licens med öppen källkod, i ett projekt som styrs av en stiftelse och inte av ett enda företag: för de jobben var den lika snabb som Redis, använde lite mindre minne för vanliga strängar och skrev ögonblicksbilder snabbare. Välj Redis om din app behöver JSON-dokument, fritextsökning, tidsserier eller vektormängder i samma server, som Redis officiella avbild har inbyggt, och AGPLv3 passar dig.

Det här testade vi

Vi installerade båda på samma nya Melonslab VC-P Alloy (2 vCPU, 8 GB) med Debian 13 och följde våra guider Valkey-server med rootless Podman och Redis-server med rootless Podman steg för steg. De körde under var sin användare, med inställningarna från sin guide: användaren default avstängd och en inloggning per app, maxmemory 4gb med noeviction, och AOF med appendfsync everysec plus ögonblicksbilder varje timme. Det enda vi ändrade var porten: Valkey på 127.0.0.1:6379 och Redis på 127.0.0.1:6380, så att båda kunde köra samtidigt. Servern hade ingen WireGuard, så vi strök den andra raden PublishPort, som båda guiderna tillåter.

Sedan testade vi en i taget, medan den andra stod stilla:

• Prestanda, med samma två verktyg mot båda: redis-benchmark 8.10 (50 klienter, SET och GET över 100 000 nycklar, värden på 100 byte, 1 KB och 16 KB, utan och med en pipeline på 16) och memtier_benchmark 2.5.2 (50 klienter, en SET per tio GET och en per en GET, värden på 100 byte och 1 KB). Varje körning gjordes tre gånger genom den publicerade porten, så som en app på servern ansluter, och två gånger inifrån varje containers eget nätverk, utan Podmans portvidarebefordran. Vi redovisar medianen.
• io-threads: samma körningar igen med io-threads 2.
• Minne: en miljon nycklar av tre slag, och tio miljoner strängar på 100 byte med slumpat innehåll, omkring 1,1 GB.
• Lagring: tider för ögonblicksbild, omskrivning av AOF och inläsning av de tio miljonerna nycklar, och säkerhetskopieringen från varje guide.
• Klienter: redis-py 8.1.0 och valkey-py 6.2.0 mot båda servrarna, över RESP2 och RESP3, och node-redis 6.3.0 mot båda.

Till sist startade vi om servern och kontrollerade att båda kom tillbaka med sin data.

Siffrorna

Minnet för datan är vad servern själv rapporterade som used_memory, och för containrarna i vila vad podman stats visade några minuter efter en omstart. Hela servern, med båda igång och Caddy från Podman-guiden, använde omkring 520 MB.

Fart

För det jobb de flesta appar ger dem, korta läsningar och skrivningar, kunde vi inte skilja dem åt. Operationer per sekund, medianen av våra körningar, med standardvärdet io-threads 1:

Samma test skilde ofta 10 till 20 % mellan körningarna på samma server, så mindre skillnader än så är brus. Redis låg lite före i de flesta körningarna med memtier, Valkey i några av dem med redis-benchmark. Svarstiden för den långsammaste procenten, p99, var 5,1 ms för Valkey och 4,7 ms för Redis i memtier-körningen utan pipeline, med testverktyget självt på samma två vCPU.

Två saker betydde mycket mer än valet av server:

• Podmans portvidarebefordran halverade farten för båda utan pipeline. Appar som ansluter via 127.0.0.1 eller WireGuard går genom den, som i våra guider. Upp till omkring 20 000 operationer i sekunden, vilket är mycket för de flesta appar, spelar den ingen roll.
• Pipelining, att skicka många kommandon innan du väntar på svaren, gav båda fyra till åtta gånger så många operationer. De flesta klientbibliotek kan det.

io-threads sprider nätverksarbetet över fler trådar och är tänkt för servrar med fler kärnor. På våra 2 vCPU blev det sämre med io-threads 2 utan pipeline: Valkey sjönk till mellan hälften och tre fjärdedelar av sin fart, och Redis till mellan 75 och 100 %, eftersom trådarna slåss med testverktyget och Podman om samma två kärnor. Med en pipeline på 16 vann Valkey upp till 27 % i memtier-körningarna och förlorade upp till en tredjedel i andra, och Redis förlorade 14 till 25 %. På en server med två kärnor låter du bli io-threads, som båda guiderna gör.

Minne

Båda håller allt i minnet, så det här avgör hur mycket data som ryms under maxmemory. För en miljon strängar eller heltal låg de inom 10 % från varandra. Med tio miljoner nycklar använde Valkey 160 MB mindre, 1,34 GB mot 1,50 GB. Valkeys versionsinformation säger att det beror på en mer kompakt tabell för nycklarna och, i 9.1, mindre overhead för korta strängar. För hashar låg Redis 8.10 före, med 135 MB för en miljon hashar mot 150 MB. Dess versionsinformation nämner en ny kompakt lagring av hashar i 8.10.

I vila använde båda omkring 10 MB.

Lagring och säkerhetskopior

Båda skriver samma sorts ögonblicksbild och samma AOF, och filerna blev lika stora. Valkey skrev ögonblicksbilden av vår 1,1 GB data på 18 sekunder och Redis på 28. I ett andra test med värden som var lätta att komprimera blev det 12 och 17 sekunder. Båda tog 26 sekunder på sig att läsa in datan vid start och svarade LOADING tills dess. En omstart tog omkring 38 sekunder totalt för båda, eftersom båda sparar en sista ögonblicksbild när de stoppas.

Den nattliga säkerhetskopieringen i varje guide ber servern om en ögonblicksbild med --rdb. För vår 1,1 GB tog det 23 sekunder med Valkey och 22 med Redis, och servern svarade under tiden. Eftersom inget ändrades under tiden stannade kopian som fork gör på omkring 1 MB för båda.

Båda startade igen av sig själva efter en omstart av servern, med alla sina nycklar.

Formaten för ögonblicksbilder har glidit isär sedan forken. Vi provade varje servers ögonblicksbild i den andra: Redis 8.10 läste in Valkeys, som bara hade vanliga nycklar, men Valkey 9.1 vägrade läsa Redis med Can't handle RDB format version 15. För att flytta från Redis till Valkey kopierar du nycklarna med ett verktyg som läser från den ena och skriver till den andra, inte dump.rdb.

Klienter

Valkey svarar som Redis 7.2.4 i INFO, plus sin egen valkey_version, så bibliotek skrivna för Redis ansluter utan ändringar. I våra tester:

• redis-py fungerade mot båda, över RESP2 och RESP3: strängar, räknare, pipelines, transaktioner, hashar med utgångstid per fält, strömmar, Lua-skript, SCAN och pub/sub. Dess JSON-kommandon fungerade bara mot Redis.
• valkey-py, Valkey-projektets fork av redis-py, fungerade också mot båda, och dess JSON-kommandon fungerade även de mot Redis. Den saknar ännu metoden hexpire(), men kommandot fungerar om du skickar det själv.
• node-redis 6.3.0, klienten som Redis underhåller, klarade allt mot båda, utgångstid per fält också, utom JSON mot Valkey.

Om en app kontrollerar versionen för en funktion som kom efter Redis 7.2 kan den se 7.2.4 från Valkey och stänga av funktionen, även när Valkey har den.

Funktioner

Grundkommandona är desamma: båda har strängar, listor, mängder, sorterade mängder, hashar med utgångstid per fält, strömmar, pub/sub, Lua och ACL. Resten skiljer sig. Vi jämförde de två servrarnas kommandolistor: med underkommandon hade Redis 669 och Valkey 399.

Redis 8 har sina tidigare moduler i den officiella avbilden och laddar dem vid start: JSON-dokument (JSON.*), sökmotorn (FT.*), tidsserier (TS.*), och Bloom- och cuckoo-filter, count-min sketch, top-k och t-digest. Den har också vektormängder (V*) för likhetssökning, en ny arraytyp (AR*), HOTKEYS för att hitta de mest använda nycklarna, och stegvisa säkerhetskopior (BACKUP). I vårt test sparade appens inloggning ett JSON-dokument och hittade det med ett sökindex, som Redis-guiden visar.

Valkey har inget av det i sin egen avbild. Dess tillägg handlar mest om driften: COMMANDLOG för långsamma och stora kommandon, DELIFEQ för att släppa lås säkert, inloggningar som bara får använda vissa databaser, och i klusterläge numrerade databaser, atomisk flytt av slots och CLUSTERSCAN. För tilläggen ger Valkey-projektet ut en andra avbild, valkey/valkey-bundle, med Valkey JSON, Valkey Bloom, Valkey Search och inloggning via LDAP. Vi startade valkey-bundle:9.1 en gång, utanför våra guider: den sparade och läste ett JSON-dokument, använde ett Bloom-filter och hittade en hash med ett sökindex på ett taggfält. Den har inga tidsserier, avbilden är dubbelt så stor med 287 MB, och vår Valkey-guide använder den inte.

Uppdateringar

Båda guiderna följer en tagg för en minor-version, 9.1 och 8.10, och podman auto-update installerar rättningarna. Redis underhåller flera minor-versioner samtidigt: avbilderna för 8.10.2 och för rättningar av 8.2 till 8.8 uppdaterades alla i oktober 2026. Valkeys tagg 9.2 pekade på en testversion när vi testade, så en tagg utan rättningsnummer är inte alltid en stabil version. Valkey-guiden förklarar det.

Debian 13 har båda i sitt eget förråd, i äldre versioner: Redis 8.0.2 och Valkey 8.1.1. Våra guider använder projektens egna avbilder i stället.

Licens och styrning

Vi kontrollerade projektens egna sidor och arkiv den 14 oktober 2026.

• Redis utvecklas av Redis Ltd. Fram till 7.2 var licensen BSD. I mars 2024 flyttade företaget Redis 7.4 till två licenser som inte är öppen källkod, RSALv2 och SSPLv1. Sedan Redis 8.0 kan du i stället välja AGPLv3, en licens med öppen källkod, och de inbyggda modulerna för JSON, sökning, tidsserier och Bloom-filter har samma tre licenser. Med AGPLv3 måste du publicera dina ändringar om du ändrar i Redis kod och låter andra använda den över nätverket. Kör du den oförändrad för dina egna appar kräver den ingenting av dig. Redis Ltd. säljer också Redis Cloud och Redis Software, med funktioner som versionen med öppen källkod saknar.
• Valkey forkades från Redis 7.2.4 i mars 2024, efter licensbytet, och har BSD-licensen med tre klausuler, liksom modulerna i valkey-bundle. Det är ett projekt under Linux Foundation, som äger namnet. En teknisk styrgrupp av utvecklarna fattar besluten, och högst en tredjedel av dem får arbeta för samma företag. När vi tittade kom de nio ansvariga utvecklarna från Amazon, Alibaba, Apple, Ericsson, Google, Oracle, Percona och Tencent. Valkey har ingen egen betalversion, men flera molnleverantörer säljer den som tjänst.

Båda är gratis att köra på din egen server. När vi avlyssnade trafiken för våra två guider kontaktade ingen av dem någon tjänst på internet.

Vilken ska du välja

Valkey passar de flesta appar som använder Redis som cache, för sessioner, köer eller gränser för antal anrop: den var lika snabb, använde lite mindre minne för vanliga nycklar, skrev ögonblicksbilder snabbare, och dess licens och styrning kan inte ändras av ett enda företag. Dess svagheter är att den officiella avbilden saknar JSON, sökning och tidsserier, att modulerna kräver en andra avbild, att INFO svarar som Redis 7.2.4, att Python-klienten ligger lite efter redis-py, och att den inte kan läsa in en ögonblicksbild från Redis 8. Följ Valkey-guiden.

Redis passar dig om din app använder JSON-dokument, sökning, tidsserier eller vektormängder, eller ett ramverk som kräver Redis 8 med namn. Dess svagheter är en licens som har bytts två gånger på två år, AGPLv3 om du ändrar i den, och ett företag som styr projektet och säljer den större versionen. Följ Redis-guiden.

Båda guiderna sätter en minnesgräns på 4 GB och går gott och väl på en VC-P Alloy, som på vår testserver. För några hundra megabyte cache behöver båda mycket lite. Vill du byta senare behöver dina appar bara en ny adress och ett nytt lösenord, men datan måste kopieras nyckel för nyckel från Redis till Valkey, eftersom ögonblicksbilderna inte går att läsa in.