Introducing HotKV

HotKV is a multithreaded, Redis-compatible data store written from scratch in modern C++, built to get the most speed out of modern many-core servers at the lowest possible cost. I'm Norbert E. Boros, founder and CEO of HotKV Ltd. This post explains why I built it, what it does today and how it measured.

In short. HotKV runs commands on many threads at once inside a single process and speaks RESP2 and RESP3, the Redis protocol. In our October 2026 single-instance benchmark on 160 vCPUs it had the highest throughput on 11 of the 12 commands we measured, and Dragonfly was level with it on the twelfth. The setup and its limits are described below.

Why I built HotKV

I care about speed in everything I build. A website, a tool or a server should respond instantly, and when it does not, I want to know why. That habit has shaped my work for as long as I have been writing software.

C and C++ have been my main languages for many years. For nearly ten years I worked on game anti-cheat software that ran on thousands of players' PCs. It had to scan memory for cheats while using as little CPU and memory as possible, because every cycle it spent was taken from the game. That work taught me to measure everything, to design around the hardware, and to treat low resource use as a feature in its own right.

Alongside it, I used Redis and Valkey in many projects that needed a fast cache: session stores, lists of IP addresses blocked by a firewall, and a cache in front of hundreds of millions of SQL Server records. They are excellent tools. They also made me curious about what a key-value store could do if it were designed from the start for the many-core servers we run today.

HotKV is the answer I arrived at. I wrote it from scratch in modern C++ to get as much speed out of the hardware as possible, at the lowest possible cost. The benchmark below shows where it stands today, and I expect there is more to gain.

The cost of AI

There was a second reason. Running AI applications was becoming expensive, for me and, judging by what developers were sharing online, for many others too. A large part of that cost often comes from sending a model questions it has already answered. A fast store that recognises a repeated or similar question and answers it from cache is one of the most direct ways to cut that bill, which is why caching for AI workloads is a core part of HotKV.

What HotKV is for

HotKV Ltd exists to make this kind of software more performant and more affordable. Modern servers have a lot of cores, and a data store should use them, so that you get as much speed as possible for the lowest possible cost.

The second idea is to keep more of the stack in one place. Teams building on LLMs often end up running a cache, a vector database and somewhere to keep agent memory, with a pile of glue code between them. I want caching and the AI work built around it to live in one engine, next to your data: exact and semantic caching of model calls, vector search, agent memory and token budgets. Fewer systems to run should mean fewer moving parts and a lower bill. The AI page lists what is available today, and the token-savings benchmark shows what caching model calls saved in our test.

HotKV keeps the Redis protocol and familiar client libraries.

The problem

A single command execution thread can become a bottleneck on a machine with many cores. A data store built around one execution thread usually reaches the rest of the machine by running several instances or a cluster, and that brings deployment choices and operational work with it. I wanted HotKV to start from the other end, with commands running concurrently inside one instance, so that a single process can use the whole machine.

What HotKV does differently

HotKV™ is written in C++20 and designed to run commands on many cores at once, so a single instance can make use of a whole machine. Dragonfly, which we benchmark below, takes a multithreaded approach too.

• Many cores, one instance. Commands run concurrently across the machine's cores, so one instance can use a large server instead of several smaller ones.
• Familiar clients and protocol. HotKV supports RESP2 and RESP3, so familiar client libraries can connect to it. Transactions (MULTI/EXEC) and Lua scripting are supported. See the command documentation for the supported commands and any differences.

How it is built and tested

I build HotKV myself and use AI assistance where it helps. What matters more than how a line was written is whether it holds up, so the engine is tested hard. It has more than 2,000 automated tests and builds under AddressSanitizer, ThreadSanitizer and UndefinedBehaviorSanitizer. It also has fuzz targets for the protocol parser, command dispatch, RDB and AOF loading, the replication stream and the cluster bus.

The benchmark setup, its limits and the full results are on the Performance page, so you can judge the numbers yourself.

Benchmark snapshot

Updated October 2026: the figures first published in this post came from benchmark runs we later found to be flawed (among other things, every load generator used the same random seed), so we replaced them with results from our rebuilt benchmark.

October 2026: HotKV, Redis, Valkey and Dragonfly

HotKV Ltd ran this benchmark. We measured HotKV, built from source, against Redis 8.10.2, Valkey 9.1.2 and Dragonfly 2.0.2. Each server ran alone, as a single instance on all 160 vCPUs of an Azure D160alds_v7 (AMD EPYC 9V45), with persistence off. Three separate 64-vCPU machines generated the load with memtier_benchmark: 256-byte values, a pipeline depth of 30 and 5,000,000 prefilled keys. Every figure is the median of three 10-second runs.

HotKV had the highest throughput on 11 of the 12 commands. Against Redis or Valkey it measured between 8.6 and at least 69.7 times their throughput, depending on the command and the server; against Dragonfly, between 1.97 and 4.41 times on those 11 commands, several of them lower bounds. On PING Dragonfly measured 0.6 percent ahead. We count that as a tie, because the load generators were close to their own limit. The highest figure on a data command was 90.8 million INCR operations per second. INCR and PING move little data and are limited by the load generators, so HotKV's own figure for them may be higher.

Reading the table

MGET reads eight keys and MSET writes four key-value pairs per command, and throughput counts commands. The report marks seven HotKV figures (GET and six write commands) because they reached its 85% network-use threshold, and PING because the load generators were above 85% CPU. Ratios built on them are lower bounds, marked with ≥. GET and PING are the real limits. For the six write commands the report's network-use figure adds inbound and outbound traffic and compares it with the outbound cap, so it overstates how close they were to a limit. The heaviest, SETNX, used at most about 80% of the measured inbound ceiling. We keep the ≥ on them as a conservative convention. The full tables, flags and method notes are on the Performance page.

Scope of the benchmark

• Build and tuning. HotKV was compiled with -march=native for the test CPU, while the other servers were their stock release builds.
• Thread settings. Every server was given all of the machine's cores: HotKV --threads 160, Dragonfly 160 proactor threads, Valkey io-threads 160 and Redis io-threads 128, its maximum. Redis and Valkey run commands on one thread and may reach higher throughput with fewer I/O threads, so their figures may be below their best. We did not run clusters or several instances of them.
• Scope. Twelve commands, one value size, one pipeline depth, no TLS and no persistence. LPOP and RPOP were not measured, because at these rates a destructive read empties any list that fits in memory within 10 seconds. The report records latency and memory use, but we do not compare them here. The servers did very different amounts of work in each 10-second run, so the memory figures are not like-for-like. Mixed workloads were not measured.
• Variation. Redis varied widely between its three runs on several commands, up to 7.2 times between its fastest and slowest run on HSET, and the median hides that. Compared with each competitor's fastest run instead of its median, HotKV still led on all 11 commands.

Redis, Valkey and Dragonfly are trademarks of their respective owners. They are named only to identify the software we measured, and this implies no sponsorship, endorsement or affiliation.

What ships today

Core command families include strings, lists, sets, hashes, sorted sets, streams, geospatial indexes, bitmaps, HyperLogLog, pub/sub and Lua scripting. The AI modules and enterprise features run on licensed plans. Pricing lists what each plan includes. See the documentation for current command coverage. Beyond the Redis command set:

• Key tagging: label keys with arbitrary tags and query by tag (TAG.SET, TAG.MEMBERS and five more commands).
• Nanosecond TTL: NEXPIRE, NTTL and NEXPIREAT set and read expiry in nanoseconds, so deadlines can be finer than a millisecond. Expired keys are reclaimed by a background sweep and when they are accessed.
• Optional value compression: for values above a size threshold (512 bytes by default), off unless you turn it on.
• Snapshots without a fork: BGSAVE writes on a background thread instead of a forked process. A snapshot is not a point-in-time copy. Each key is saved as it was when the snapshot reached it. Rewriting the append-only file does fork.
• Prometheus metrics: a built-in HTTP endpoint, off by default and enabled with metrics-port, so no external exporter is needed.

HotKV also has built-in vector search with HNSW indexes (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). We measured it against Redis 8 in Vector search: HotKV vs Redis 8 vector sets, from 1 to 100 clients.

Get started on HotKV Cloud, or talk to sales about running HotKV on your own servers.