Kennismaking met HotKV

HotKV is een multithreaded, Redis-compatibele datastore die from scratch in modern C++ is geschreven, gebouwd om zoveel mogelijk snelheid uit moderne servers met veel cores te halen, tegen de laagst mogelijke kosten. Ik ben Norbert E. Boros, oprichter en CEO van HotKV Ltd. Dit bericht legt uit waarom ik hem bouwde, wat hij nu doet en hoe hij gemeten is.

Kort samengevat. HotKV voert commando's op veel threads tegelijk uit binnen één proces en spreekt RESP2 en RESP3, het Redis-protocol. In onze benchmark met één instantie op 160 vCPU's van oktober 2026 had hij de hoogste doorvoer op 11 van de 12 commando's die we maten, en Dragonfly stond bij het twaalfde gelijk met hem. De opzet en de beperkingen worden hieronder beschreven.

Waarom ik HotKV bouwde

Snelheid is voor mij in alles wat ik bouw belangrijk. Een website, een tool of een server moet direct reageren, en als dat niet zo is, wil ik weten waarom. Die gewoonte heeft mijn werk gevormd zolang ik software schrijf.

C en C++ zijn al jaren mijn belangrijkste talen. Bijna tien jaar werkte ik aan anti-cheatsoftware voor games die op de pc's van duizenden spelers draaide. Die moest het geheugen op cheats scannen en daarbij zo weinig mogelijk CPU en geheugen gebruiken, omdat elke cyclus die het verbruikte van de game werd afgenomen. Dat werk leerde me alles te meten, rond de hardware te ontwerpen en laag resourcegebruik als een functie op zich te beschouwen.

Daarnaast gebruikte ik Redis en Valkey in veel projecten die een snelle cache nodig hadden: sessiestores, lijsten met IP-adressen die door een firewall werden geblokkeerd, en een cache voor honderden miljoenen SQL Server-records. Het zijn uitstekende tools. Ze maakten me ook nieuwsgierig naar wat een key-valuestore zou kunnen als hij vanaf het begin was ontworpen voor de servers met veel cores die we tegenwoordig draaien.

HotKV is het antwoord waar ik op uitkwam. Ik schreef hem from scratch in modern C++ om zoveel mogelijk snelheid uit de hardware te halen, tegen de laagst mogelijke kosten. De benchmark hieronder laat zien waar hij nu staat, en ik verwacht dat er nog meer te winnen valt.

De kosten van AI

Er was een tweede reden. AI-toepassingen draaien werd duur, voor mij en, te oordelen naar wat ontwikkelaars online deelden, ook voor veel anderen. Een groot deel van die kosten komt vaak voort uit het sturen van vragen naar een model die het al heeft beantwoord. Een snelle store die een herhaalde of vergelijkbare vraag herkent en hem uit de cache beantwoordt, is een van de meest directe manieren om die rekening te verlagen, en daarom is caching voor AI-workloads een kernonderdeel van HotKV.

Waar HotKV voor dient

HotKV Ltd bestaat om dit soort software performanter en betaalbaarder te maken. Moderne servers hebben veel cores, en een datastore hoort ze te gebruiken, zodat je zoveel mogelijk snelheid krijgt tegen de laagst mogelijke kosten.

Het tweede idee is om meer van de stack op één plek te houden. Teams die op LLM's bouwen draaien vaak uiteindelijk een cache, een vectordatabase en een plek om agentgeheugen te bewaren, met een berg lijmcode ertussen. Ik wil dat caching en het AI-werk eromheen in één engine leven, naast je data: exacte en semantische cache van modelaanroepen, vectorzoeken, agentgeheugen en tokenbudgetten. Minder systemen om te draaien zou minder bewegende delen en een lagere rekening moeten betekenen. De AI-pagina toont wat er nu beschikbaar is, en de benchmark voor tokenbesparing laat zien wat het cachen van modelaanroepen in onze test bespaarde.

HotKV behoudt het Redis-protocol en vertrouwde clientbibliotheken.

Het probleem

Eén thread voor commando-uitvoering kan een bottleneck worden op een machine met veel cores. Een datastore die rond één uitvoerthread is gebouwd, bereikt de rest van de machine meestal door meerdere instanties of een cluster te draaien, en dat brengt keuzes bij de uitrol en operationeel werk met zich mee. Ik wilde dat HotKV aan de andere kant begon, met commando's die gelijktijdig binnen één instantie draaien, zodat één proces de hele machine kan gebruiken.

Wat HotKV anders doet

HotKV™ is geschreven in C++20 en ontworpen om commando's op veel cores tegelijk uit te voeren, zodat één instantie een hele machine kan benutten. Dragonfly, die we hieronder benchmarken, kiest ook een multithreaded aanpak.

• Veel cores, één instantie. Commando's draaien gelijktijdig over de cores van de machine, dus één instantie kan een grote server gebruiken in plaats van meerdere kleinere.
• Vertrouwde clients en protocol. HotKV ondersteunt RESP2 en RESP3, zodat vertrouwde clientbibliotheken er verbinding mee kunnen maken. Transacties (MULTI/EXEC) en Lua-scripting worden ondersteund. Zie de commandodocumentatie voor de ondersteunde commando's en eventuele verschillen.

Hoe het is gebouwd en getest

Ik bouw HotKV zelf en gebruik AI-hulp waar die helpt. Belangrijker dan hoe een regel is ontstaan, is of hij standhoudt, dus de engine wordt hard getest. Hij heeft meer dan 2.000 geautomatiseerde tests en wordt gebouwd onder AddressSanitizer, ThreadSanitizer en UndefinedBehaviorSanitizer. Daarnaast zijn er fuzz-targets voor de protocolparser, de commandodispatch, het laden van RDB en AOF, de replicatiestream en de clusterbus.

De benchmarkopzet, de beperkingen en de volledige resultaten staan op de pagina Performance, zodat je de cijfers zelf kunt beoordelen.

Benchmark in het kort

Bijgewerkt in oktober 2026: de cijfers die oorspronkelijk in dit bericht werden gepubliceerd kwamen uit benchmarkruns waarvan we later ontdekten dat ze gebrekkig waren (onder meer gebruikte elke loadgenerator dezelfde random seed), dus we hebben ze vervangen door resultaten uit onze herbouwde benchmark.

Oktober 2026: HotKV, Redis, Valkey en Dragonfly

HotKV Ltd voerde deze benchmark uit. We maten HotKV, vanuit de broncode gebouwd, tegen Redis 8.10.2, Valkey 9.1.2 en Dragonfly 2.0.2. Elke server draaide alleen, als enkele instantie op alle 160 vCPU's van een Azure D160alds_v7 (AMD EPYC 9V45), met persistentie uit. Drie aparte machines met 64 vCPU's genereerden de belasting met memtier_benchmark: waarden van 256 bytes, een pipelinediepte van 30 en 5.000.000 vooraf gevulde sleutels. Elk cijfer is de mediaan van drie runs van 10 seconden.

HotKV had de hoogste doorvoer op 11 van de 12 commando's. Tegenover Redis of Valkey mat hij tussen 8,6 en minstens 69,7 keer hun doorvoer, afhankelijk van het commando en de server; tegenover Dragonfly tussen 1,97 en 4,41 keer op die 11 commando's, waarvan meerdere ondergrenzen. Bij PING mat Dragonfly 0,6 procent voor. Dat rekenen we als gelijkspel, omdat de loadgenerators dicht bij hun eigen limiet zaten. Het hoogste cijfer op een datacommando was 90,8 miljoen INCR-bewerkingen per seconde. INCR en PING verplaatsen weinig data en worden beperkt door de loadgenerators, dus het eigen cijfer van HotKV daarvoor kan hoger zijn.

De tabel lezen

MGET leest acht sleutels en MSET schrijft vier sleutel-waardeparen per commando, en de doorvoer telt commando's. Het rapport markeert zeven cijfers van HotKV (GET en zes schrijfcommando's) omdat ze de drempel van 85% netwerkgebruik bereikten, en PING omdat de loadgenerators boven 85% CPU zaten. Verhoudingen die erop zijn gebouwd zijn ondergrenzen, gemarkeerd met ≥. GET en PING zijn de echte limieten. Bij de zes schrijfcommando's telt het netwerkgebruik in het rapport inkomend en uitgaand verkeer bij elkaar op en vergelijkt het met de uitgaande limiet, waardoor het overdrijft hoe dicht ze bij een limiet zaten. Het zwaarste, SETNX, gebruikte hooguit ongeveer 80% van het gemeten inkomende plafond. We behouden de ≥ bij deze cijfers als conservatieve conventie. De volledige tabellen, markeringen en methodenotities staan op de pagina Performance.

Reikwijdte van de benchmark

• Build en tuning. HotKV is gecompileerd met -march=native voor de test-CPU, terwijl de andere servers hun standaard releasebuilds waren.
• Threadinstellingen. Elke server kreeg alle cores van de machine: HotKV --threads 160, Dragonfly 160 proactor-threads, Valkey io-threads 160 en Redis io-threads 128, het maximum. Redis en Valkey voeren commando's op één thread uit en kunnen met minder I/O-threads een hogere doorvoer halen, dus hun cijfers liggen mogelijk onder hun best mogelijke. We hebben geen clusters of meerdere instanties ervan gedraaid.
• Reikwijdte. Twaalf commando's, één waardegrootte, één pipelinediepte, geen TLS en geen persistentie. LPOP en RPOP zijn niet gemeten, omdat bij deze snelheden een destructieve read elke lijst die in het geheugen past binnen 10 seconden leegmaakt. Het rapport legt latentie en geheugengebruik vast, maar we vergelijken ze hier niet. De servers deden in elke run van 10 seconden zeer verschillende hoeveelheden werk, dus de geheugencijfers zijn niet vergelijkbaar. Gemengde workloads zijn niet gemeten.
• Variatie. Redis varieerde sterk tussen zijn drie runs op meerdere commando's, tot 7,2 keer tussen zijn snelste en traagste run op HSET, en de mediaan verbergt dat. Vergeleken met de snelste run van elke concurrent in plaats van de mediaan leidde HotKV nog steeds op alle 11 commando's.

Redis, Valkey en Dragonfly zijn handelsmerken van hun respectieve eigenaren. Ze worden alleen genoemd om de software te identificeren die we hebben gemeten, en dit impliceert geen sponsoring, goedkeuring of verbondenheid.

Wat er nu wordt geleverd

Kerncommandofamilies omvatten strings, lijsten, sets, hashes, sorted sets, streams, geospatiale indexen, bitmaps, HyperLogLog, pub/sub en Lua-scripting. De AI-modules en enterprise-functies draaien op gelicentieerde plannen. Prijzen toont wat elk plan bevat. Zie de documentatie voor de actuele dekking van commando's. Naast de Redis-commandoset:

• Key tagging: label sleutels met willekeurige tags en bevraag ze op tag (TAG.SET, TAG.MEMBERS en vijf andere commando's).
• TTL in nanoseconden: NEXPIRE, NTTL en NEXPIREAT stellen de verloopdatum in en lezen hem uit in nanoseconden, zodat deadlines fijner kunnen zijn dan een milliseconde. Verlopen sleutels worden vrijgegeven door een achtergrondsweep en wanneer ze worden benaderd.
• Optionele waardecompressie: voor waarden boven een groottedrempel (standaard 512 bytes), uit tenzij je het inschakelt.
• Snapshots zonder fork: BGSAVE schrijft op een achtergrondthread in plaats van in een geforkt proces. Een snapshot is geen point-in-time-kopie. Elke sleutel wordt opgeslagen zoals hij was toen de snapshot hem bereikte. Het herschrijven van de append-only file doet wel een fork.
• Prometheus-metrics: een ingebouwd HTTP-endpoint, standaard uit en ingeschakeld met metrics-port, zodat geen externe exporter nodig is.

HotKV heeft ook ingebouwd vectorzoeken met HNSW-indexen (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). We maten het tegen Redis 8 in Vectorzoeken: HotKV vs Redis 8 vector sets, van 1 tot 100 clients.

Ga aan de slag op HotKV Cloud, of neem contact op met sales over het draaien van HotKV op je eigen servers.