KiviDB 1.2.0 against Redis, Redis Cluster, Valkey, Dragonfly, Garnet and kvrocks: throughput, latency, memory, snapshots, vector search, caching and durability, where KiviDB loses, and a downloadable report.
KiviDB 1.2.0 against Redis, Redis Cluster, Valkey, Dragonfly, Garnet and kvrocks on the same Azure VMs, in the same hour (Azure VMs and AKS, 1 to 3 November 2026). Every number is in https://github.com/kividbio/kividb/blob/main/benchmarks/1.2.0/REPORT.md; a 15-page PDF report with every comparison, KiviDB Cloud's features and prices can be downloaded from this page.
KiviDB 1.2.0 results
| KiviDB 1.2.0 | Best other | Redis 8.10.3 | |
|---|---|---|---|
| GET 100 B, pipeline 16 | 10.45M ops/s | Garnet 10.69M | 1.41M |
| SET 100 B, pipeline 16 | 7.94M ops/s | Garnet 9.83M | 1.25M |
| MSET of 10 keys | 569K commands/s | Garnet 800K | 144K |
| Lists, hashes, sets, sorted sets, counters, pipeline 16 | 4.2-6.6M ops/s | Redis Cluster x16: level | 3.7-6.0x less |
| Bytes per key, 100 B values, 50M keys | 140.7 | Dragonfly 141.5 | 174.4 |
| Memory added by BGSAVE, 30M keys of 1 KB under writes | +10% | Dragonfly +0.4% | +89% |
| Filtered vector search, 100 clients | 4,478 q/s | Dragonfly 811 | 1,802 |
| Cache hit rate, issue #202 | 60.96% | 60.78% | |
| Acknowledged writes lost to kills, failovers, power loss, forced deletes | 0 | 0 |
Where KiviDB loses
- Garnet Faster on SET at pipeline 16 (9.83M against 7.94M ops/s) and on MSET of 10 keys (800K against 569K). KiviDB's MSET has the lower tail: p99 2.89 against 7.90 ms.
- Redis Cluster With 16 shards, one per vCPU, ahead on HSET and INCR at pipeline 16, where the load generator is the limit.
- Dragonfly Uses less memory per vector and during a snapshot (+0.4% against +10%), and fewer bytes per key for ASCII values (137.1 against 149.2).
- Redis Ingests vectors faster, and serves 3-9% more cache GETs a second in the #202 test.
KiviDB 1.2.0 on bare metal
AWS Graviton3 bare metal: the server on a c7gn.metal confined to 32 cores, the load generator on a second c7gn.metal in the same placement group, one engine at a time. KiviDB 1.2.0, Garnet 2.2.5 (shown only where KiviDB leads it), Dragonfly 2.0.2, Redis 8.10.3. memtier_benchmark, 10 million keys of 100 bytes.
Throughput
| Run | KiviDB | Garnet | Dragonfly | Redis |
|---|---|---|---|---|
| GET, pipeline 16 | 21.24M ops/s | 20.82M ops/s | 9.31M ops/s | 2.36M ops/s |
| SET, pipeline 16 | 17.79M ops/s | - | 8.70M ops/s | 1.94M ops/s |
| GET, no pipelining | 2.99M ops/s | 2.88M ops/s | 3.30M ops/s | 1.47M ops/s |
| SET, no pipelining | 3.22M ops/s | 3.07M ops/s | 3.37M ops/s | 1.26M ops/s |
Tail latency
- GET, pipeline 16, p99 latency: KiviDB 0.36 ms, Dragonfly 0.88 ms, Redis 2.29 ms
- SET, pipeline 16, p99 latency: KiviDB 0.45 ms, Dragonfly 1.02 ms, Redis 2.72 ms
Memory per key
- KiviDB: 143 bytes
- Dragonfly: 134 bytes
- Redis: 178 bytes
What these numbers do not cover
Persistence was off for every engine; one value size (100 bytes) and one machine size (32 cores) are published; Valkey and KeyDB were not measured on bare metal; single nodes without replication or TLS. The scripts are public at https://github.com/kividbio/kivi-benchmark, and an automated run on different hardware is in https://github.com/kividbio/kividb/blob/master/benchmarks/LATEST.md.