Redis vs Valkey vs Dragonfly vs KiviDB

What did we learn?

Dragonfly took the p99 and memory sections, KiviDB took pipelining by 33% and out-served it on small values in every pass, and the two tied at 10 KB on the network ceiling.

KiviDB 1.1.2 ran its default 62 worker threads and Dragonfly 2.0.2 its default 64, both on io_uring. On 100-byte SET/GET, KiviDB's slowest pass (1.44M ops/s) beat Dragonfly's fastest (1.41M); Dragonfly's p99 was lower, 0.45 ms to 0.46, by less than either engine's spread between passes. At pipeline depth 30 KiviDB did 22.2M ops/s to Dragonfly's 16.7M, and that's a floor: the client sat at 66 to 70% CPU and KiviDB's passes slowed as it climbed. At 10 KB both did 398K ops/s, 29.6 Gbit/s against the instances' 30 Gbit/s rating, a tie. Memory went to Dragonfly: 118 bytes of RSS per key to KiviDB's 267, Redis's 165 and Valkey's 170. Redis 8.10.3 and Valkey 9.1.3 stayed within 1% of each other everywhere but pipeline 30, where Redis led by 8%. A second run under Docker's stock seccomp profile, which blocks io_uring, cost KiviDB 33% of its small-value throughput and Dragonfly nothing measurable. Medians of ten passes; the table shows means.

What this does not prove

• KiviDB's pipeline-30 cell ran the client at 66 to 70% CPU, where 50 memtier threads can keep at most 50 of its 64 vCPUs busy, and KiviDB's passes got slower as client CPU rose, so its 22.2M ops/s is a floor.
• At 10 KB, Dragonfly and KiviDB both delivered 398K ops/s, which is 29.6 Gbit/s of values into the client against the instances' 30 Gbit/s rating, so that section measures the network and can't separate them.
• Latency is closed-loop at 200 connections and measured at the client, so each engine's p99 comes at its own throughput. Between passes, p99 swung by 23 to 59% of its median in Dragonfly's and KiviDB's small- and large-value cells, far more than the gaps between them.
• Docker's default seccomp profile blocks io_uring, so this run allowed io_uring_setup, io_uring_enter and io_uring_register on top of it. In the second 2026-10-29 run, under the stock profile, Dragonfly fell back to epoll with no measurable change, while KiviDB fell back to tokio and lost 33% of its small-value throughput and 9% at pipeline 30.
• The two 2026-10-29 runs used different instance pairs, and Redis and Valkey, which have no io_uring code path, differed by up to 5.3% between them, so a gap under about 5% between the runs can't be put down to the seccomp profile.
• These numbers don't compare with the 2026-08-31 post's: the client is now a c7g.16xlarge at 200 connections instead of a c7g.4xlarge at 196, io_uring is allowed through seccomp, and every engine is a newer release. That post's Dragonfly most likely ran on epoll too, since it used the same AMI and Docker's default profile, but no startup log was kept to show it either way.
• Dragonfly ran 64 proactor threads, its default on 64 cores, and KiviDB its default 62 worker threads (cores minus two), both read from their startup logs. Redis and Valkey ran their default single-threaded I/O (io-threads 1); turning on their I/O threads is a different benchmark.
• Persistence was off for all four. For KiviDB that's its default: no AOF, and snapshots only on an explicit SAVE or BGSAVE.
• The official Redis 8.10.3 image loads its bundled Search, JSON, TimeSeries and Bloom modules, and they were left on as shipped; they add about 12 MB of baseline RSS over Valkey and don't affect GET or SET.
• Memory is the baseline-corrected used_memory_rss delta after loading 1,000,000 keys with 100-byte values into a fresh engine: 267 B per key for KiviDB, 118 for Dragonfly, 165 for Redis and 170 for Valkey. Dragonfly's per-shard tables scale with its thread count, so its fixed cost differs at other thread counts.
• memtier's default value is 100 ASCII bytes, and Dragonfly packs an all-ASCII value into 7 bits per byte, so it stores each of these values in 88 bytes where the other three store 100; binary values wouldn't pack, so the next run adds a second memory cell loaded with random bytes. Dragonfly's RSS delta also leaves out its 112 MB idle RSS, which the keys partly fill: by its own used_memory it added 130 bytes per key.
• The rig was one c7g.metal engine host and one c7g.16xlarge client in a single cluster placement group in us-east-1, speaking RESP2 without TLS. maxmemory was 16 GiB for all four, and eviction never triggered: working sets stay at or below half of it.
• KiviDB checks GitHub for a newer release at startup, before it listens; that was left on, as shipped.

Rerun it yourself: the runner and configuration are in the repository, and the methodology page covers what every run holds constant. Think a result is wrong? Open an issue with your rig and your samples.

Redis is a registered trademark of Redis Ltd. Valkey is a trademark of The Linux Foundation. Dragonfly is a trademark of DragonflyDB Ltd. KiviDB is a trademark of KIVIDB PRIVATE LIMITED.