One machine, 16 cores, loopback. Every figure is reproducible from bench/ in the repository. Read the last two rows before you decide anything — they are the ones where speed is not a reason to switch.
50 connections, pipelines of 16, small values, each engine on 4 cores. Median of 15 windows (3 rounds of 5), counted from each server's own command counter over three-second windows rather than from the benchmark client's reported rate. A ≥ marks a number the load generator set: the engine does at least that, and such a competitor number gets no ratio.
| kevy 7.0.0 | Redis 8.10.2 | valkey 9.1.2 | Dragonfly 2.0.0 | vs Redis 8.10.2 | |
|---|---|---|---|---|---|
| GET | 8,726,283 | 5,467,748 | 4,041,855 | ≥ 3,364,079 | *1.60× |
| SET | ≥ 7,409,590 | 2,861,941 | 2,011,380 | 2,019,740 | *≥ 2.59× |
| INCR | 7,249,946 | 3,788,318 | 2,750,827 | 2,223,491 | *1.91× |
| SADD | 6,919,570 | 4,204,106 | 2,728,331 | 1,911,038 | *1.65× |
| HSET | ≥ 5,393,670 | 3,352,393 | 2,283,589 | 1,964,211 | *≥ 1.61× |
| LPUSH | 4,424,738 | 3,220,774 | 2,260,722 | 1,700,519 | *1.37× |
| ZADD | ≥ 4,980,252 | 3,112,253 | 2,159,811 | 1,804,781 | *≥ 1.60× |
LPUSH is 37% ahead of Redis 8.10.2, the narrowest row. At that margin your value sizes and key distribution weigh as much as the engine — if lists are your hot path, benchmark your own workload before you switch for speed.
It is loopback. There is no network here, and in a real deployment the network is usually what you are waiting for. An engine 2× faster at GET will not make your p99 2× better if most of your latency is the wire.
The values are small. At 64 KB per value the whole thing becomes bound by the kernel's TCP path and the gap closes to single digits. If you store large blobs, these numbers are not about you.
It is one machine. kevy has no cluster mode. If your problem is that a single machine is not enough, no number on this page helps.
What you actually ship to a tab.
| Size | ||
|---|---|---|
| kevy.wasm | 1865 KB | the engine, uncompressed |
| gzipped | 639 KB | what crosses the wire |
| Cold start | < 20 ms | compile and instantiate, warm cache |
localStorage beats kevy on a small synchronous read, and always will — it is a map in the page's own address space. kevy wins on the things that make localStorage a bad idea anyway: real TTLs, no 5 MB ceiling, byte values rather than strings, and writes that do not block the main thread.
git clone https://github.com/goliajp/kevy && cd kevy
cargo build --release -p kevy
# four-way: kevy, Redis 8, valkey, Dragonfly
bash bench/arena.sh target/release/kevy
# two kevy builds side by side: the last release against this tree
bash bench/perfgate.sh compare last-release HEADTwo scripts. Everything on this page comes out of them.