LavikPERFORMANCE · ARCHITECTURE · COST
Lavik vs DragonflyDB
Billion-key reads without the same tail-latency penalty.
Lavik vs DragonflyDB SSD tiering: billion-key GET/SET benchmarks, p99 latency, node-cost scenarios, and version-aware data-structure support.
By the Lavik project · Sources checked: 2026-10-13 · Dragonfly 1.40.2 · Tiered Storage
SEPTEMBER 18, 2026 · BETA.1
Performance, with the measurements attached
1B keys × 1 KiB values; AMD EPYC 9V74, approximately 126 GiB RAM, six NVMe devices, 16-logical-CPU affinity, pipeline=1. Each point measured once for 60 seconds. Peer controls come from an earlier sweep on the same hosts; beta.1 SPDK points are newly measured. Each operation selects each system's highest-QPS point; connection counts can differ. Method and full report ↗
| Workload | System | QPS | p99 (ms) | p99.9 (ms) | Connections |
|---|---|---|---|---|---|
| GET | Lavik 0.1.0-beta.1 SPDK | 952,560 | 3.599 | 5.535 | 640 |
| GET | Dragonfly 1.40.2 · Tiered Storage | 466,039 | 38.911 | 100.863 | 1280 |
| SET | Lavik 0.1.0-beta.1 SPDK | 764,939 | 10.879 | 16.639 | 1280 |
| SET | Dragonfly 1.40.2 · Tiered Storage | 539,616 | 14.591 | 32.127 | 640 |
What this result does—and does not—establish
The billion-key run gives Dragonfly 96 GiB maxmemory and files on RAID0/XFS across the same six NVMe devices used raw by Lavik SPDK. Dragonfly receives a 180-second GET warmup. These are different storage configurations, not an isolated test of a single architectural feature. Compare complete points, including connections and p99.
These are Lavik-published benchmarks, not an independent reproduction. Short single-server windows do not establish equal crash durability, long-term steady state, cluster capacity or an application SLA. Match your workload, data distribution and latency budget before using the cost model.
Inspect the full connection and thread sweep
| System | Workload | Threads* | Connections | QPS | p99 (ms) |
|---|---|---|---|---|---|
| Lavik | GET | 16 | 80 | 396,645 | 0.319 |
| Lavik | GET | 16 | 160 | 598,462 | 0.503 |
| Lavik | GET | 16 | 320 | 792,119 | 0.959 |
| Lavik | GET | 16 | 640 | 952,560 | 3.599 |
| Lavik | GET | 16 | 1280 | 903,055 | 9.279 |
| Lavik | GET | 16 | 2560 | 801,680 | 34.815 |
| Lavik | SET | 16 | 80 | 422,450 | 0.711 |
| Lavik | SET | 16 | 160 | 530,672 | 3.759 |
| Lavik | SET | 16 | 320 | 621,373 | 6.111 |
| Lavik | SET | 16 | 640 | 717,578 | 7.839 |
| Lavik | SET | 16 | 1280 | 764,939 | 10.879 |
| Lavik | SET | 16 | 2560 | 727,984 | 18.431 |
| DragonflyDB | GET | 16 | 80 | 165,571 | 4.223 |
| DragonflyDB | GET | 16 | 160 | 376,337 | 3.279 |
| DragonflyDB | GET | 16 | 320 | 366,428 | 9.983 |
| DragonflyDB | GET | 16 | 640 | 415,906 | 21.375 |
| DragonflyDB | GET | 16 | 1280 | 466,039 | 38.911 |
| DragonflyDB | GET | 16 | 2560 | 422,117 | 82.943 |
| DragonflyDB | SET | 16 | 80 | 353,266 | 1.967 |
| DragonflyDB | SET | 16 | 160 | 454,254 | 3.359 |
| DragonflyDB | SET | 16 | 320 | 526,022 | 7.391 |
| DragonflyDB | SET | 16 | 640 | 539,616 | 14.591 |
| DragonflyDB | SET | 16 | 1280 | 524,890 | 27.135 |
| DragonflyDB | SET | 16 | 2560 | 474,635 | 51.455 |
*Thread roles differ: Lavik workers, Redis/Valkey I/O threads, Dragonfly proactors, and Garnet minimum thread-pool threads. CSV ↗
How the storage design affects your application
Both systems can use NVMe SSD; the distinction is how they serve data beyond RAM. Dragonfly's tiering controls offload and promotion around memory thresholds. Lavik's durable value representation is served through its storage engine, with worker-owned indexes and asynchronous NVMe I/O.
Lavik stores strings, hashes, lists, sets and sorted-set payloads through its SSD-capable storage engine. Dragonfly's standard tiering focuses on strings; official documentation also describes experimental list-node and hash offloading. Therefore a blanket 'Dragonfly only supports strings on SSD' claim is outdated. The supplied benchmark measures string GET/SET, not these collection paths.
Dragonfly SSD tiering documentation ↗ · Dragonfly GA announcement and experimental collection tiering ↗ · Lavik beta.1 storage and recovery ↗
FAMILIAR PROTOCOL. NVMe SSD EXECUTION.
The architecture changes. Your application protocol stays familiar.
Lavik is an Apache 2.0 open-source, Redis-compatible key-value store. Memory holds the key index; NVMe SSD holds value data. Worker-local state, coroutines and asynchronous I/O let workers advance other requests while storage completes. SPDK provides a direct NVMe storage path. The September SPDK experiment still uses kernel TCP, not DPDK networking.
The storage engine covers string, hash, list, set and sorted-set payloads, including grouped collection storage. Key indexes, routing metadata and buffers still consume RAM. String GET/SET benchmarks do not establish the same QPS for other data structures. beta.1 architecture ↗ · Storage and collections ↗ · Apache 2.0 ↗
Same SSD prices can still mean different node counts
ILLUSTRATIVE MODEL · EDIT THE ASSUMPTIONS
Same dataset. Same target QPS. How many nodes?
Defaults assume 1 TiB of values, 1 TiB usable value capacity per primary, 1 million QPS, 70% of observed throughput, two complete copies, and $1,000 per node per month. Both node prices are editable.
| System | Selected QPS / p99 | Primaries / total nodes | Assumed monthly cost |
|---|---|---|---|
| Lavik SPDK | 952,560 / 3.599 ms | 2 / 4 | $4,000 |
| DragonflyDB | 466,039 / 38.911 ms | 4 / 8 | $8,000 |
Primaries = max(⌈data / usable capacity⌉, ⌈target QPS / (observed QPS × utilization)⌉)
Total nodes = primaries × copies; monthly cost = total nodes × node price. Replicas contribute no extra serving QPS here. Assumes balanced sharding, linearly reusable per-node performance, usable capacity after space/metadata reserves, and sufficient RAM for indexes and buffers; changing per-node data size can change throughput. Replication overhead, post-failure headroom, networking and backups are not modeled. The p99 filter selects observed points; it does not establish a cluster or application SLA, especially P99.99.
When to choose Lavik
Prioritize Lavik for broad random access to a large value set, or when growing hashes, lists, sets and sorted sets also need SSD capacity. Higher observed throughput per server can translate into fewer provisioned nodes; the sizing model below makes that inference explicit.
When keeping your current system makes sense
Dragonfly remains worth evaluating when your working set stays hot in RAM or your string-tiering workload already meets its latency budget. Recheck current experimental collection support against your exact data shapes rather than assuming benchmark GET/SET results predict collection performance.
From evaluation to migration
- Inventory commands, data types, scripts and client options against the versioned compatibility coverage. Command reference · Client compatibility
- Replay your data distribution, expiry rate and read/write mix on representative NVMe SSD hardware. Compare target p99/p99.9 rather than only peak QPS.
- Validate replication, recovery and capacity headroom during failures, then make a small, reversible traffic cutover. Migration and cluster guides
Frequently asked questions
Can both Lavik and Dragonfly use SSD for Redis data?
Yes. Lavik's storage engine covers string, hash, list, set and sorted-set payloads. Dragonfly supports string tiering and documents experimental list/hash tiering with restrictions. Both still use memory; neither makes metadata and buffers free.
Does Lavik require a new application protocol?
No. Lavik accepts Redis/Valkey-compatible commands, with RESP2 by default and negotiable RESP3. Verify exact behavior against the beta.1 command reference, client compatibility and migration guides; protocol compatibility does not mean every command, module or failover behavior is identical.
How should I use a single-server benchmark for cost planning?
Select an observed point matching your read/write mix and latency budget, then account for both capacity-driven and QPS-driven node counts. Include index memory, replication, headroom and failures in your replay. The page's cost model is an explicit planning illustration, not a measured cluster result or cloud quote.
Sources and versions
Benchmarks are pinned to an upstream commit; product documentation was checked on the date shown. Historical August builds and September beta.1 results retain their own scope and are not combined across experiments.
APACHE 2.0 · REDIS COMPATIBLE · NVMe SSD