LavikPERFORMANCE · ARCHITECTURE · COST
Lavik vs Valkey
Keep the protocol. Change the economics of capacity.
Lavik vs Valkey 9.1.0: higher measured peak GET and SET QPS on NVMe SSD, the SET latency tradeoff, and DRAM versus SSD capacity economics.
By the Lavik project · Sources checked: 2026-10-13 · Valkey 9.1.0 · DRAM
SEPTEMBER 18, 2026 · BETA.1
Performance, with the measurements attached
10M 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 30 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 | 1,012,180 | 3.599 | 5.631 | 640 |
| GET | Valkey 9.1.0 · DRAM | 965,697 | 4.543 | 8.159 | 1280 |
| SET | Lavik 0.1.0-beta.1 SPDK | 930,465 | 4.799 | 8.095 | 1280 |
| SET | Valkey 9.1.0 · DRAM | 802,519 | 4.383 | 8.895 | 1280 |
What this result does—and does not—establish
Lavik has higher peak GET and SET QPS in this sweep. Valkey's selected peak SET point has lower p99 latency: 4.383 ms versus Lavik's 4.799 ms. The report includes Valkey's 1/2/4/8/16 I/O-thread configurations; the best SET result uses eight, not sixteen. Valkey persistence was disabled.
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 | 390,494 | 0.335 |
| Lavik | GET | 16 | 160 | 609,161 | 0.487 |
| Lavik | GET | 16 | 320 | 803,016 | 0.959 |
| Lavik | GET | 16 | 640 | 1,012,180 | 3.599 |
| Lavik | GET | 16 | 1280 | 940,713 | 9.791 |
| Lavik | SET | 16 | 80 | 473,384 | 0.591 |
| Lavik | SET | 16 | 160 | 633,849 | 1.071 |
| Lavik | SET | 16 | 320 | 759,488 | 1.671 |
| Lavik | SET | 16 | 640 | 876,266 | 3.567 |
| Lavik | SET | 16 | 1280 | 930,465 | 4.799 |
| Valkey | GET | 1 | 80 | 145,676 | 0.895 |
| Valkey | GET | 1 | 160 | 153,278 | 1.895 |
| Valkey | GET | 1 | 320 | 155,408 | 3.935 |
| Valkey | GET | 1 | 640 | 153,631 | 8.095 |
| Valkey | GET | 1 | 1280 | 140,694 | 17.151 |
| Valkey | SET | 1 | 80 | 143,506 | 0.871 |
| Valkey | SET | 1 | 160 | 145,804 | 1.967 |
| Valkey | SET | 1 | 320 | 145,608 | 4.159 |
| Valkey | SET | 1 | 640 | 141,952 | 8.767 |
| Valkey | SET | 1 | 1280 | 130,767 | 18.303 |
| Valkey | GET | 2 | 80 | 162,097 | 0.663 |
| Valkey | GET | 2 | 160 | 152,944 | 1.223 |
| Valkey | GET | 2 | 320 | 157,562 | 2.207 |
| Valkey | GET | 2 | 640 | 158,224 | 4.607 |
| Valkey | GET | 2 | 1280 | 149,710 | 11.711 |
| Valkey | SET | 2 | 80 | 144,667 | 0.743 |
| Valkey | SET | 2 | 160 | 151,504 | 1.247 |
| Valkey | SET | 2 | 320 | 146,800 | 2.351 |
| Valkey | SET | 2 | 640 | 148,389 | 4.927 |
| Valkey | SET | 2 | 1280 | 134,252 | 12.415 |
| Valkey | GET | 4 | 80 | 408,344 | 0.327 |
| Valkey | GET | 4 | 160 | 424,952 | 0.551 |
| Valkey | GET | 4 | 320 | 440,409 | 0.951 |
| Valkey | GET | 4 | 640 | 446,155 | 1.823 |
| Valkey | GET | 4 | 1280 | 442,891 | 3.695 |
| Valkey | SET | 4 | 80 | 381,336 | 0.359 |
| Valkey | SET | 4 | 160 | 396,496 | 0.575 |
| Valkey | SET | 4 | 320 | 405,794 | 1.031 |
| Valkey | SET | 4 | 640 | 409,712 | 1.871 |
| Valkey | SET | 4 | 1280 | 409,846 | 4.447 |
| Valkey | GET | 8 | 80 | 542,966 | 0.287 |
| Valkey | GET | 8 | 160 | 667,212 | 0.551 |
| Valkey | GET | 8 | 320 | 789,831 | 1.159 |
| Valkey | GET | 8 | 640 | 831,080 | 3.503 |
| Valkey | GET | 8 | 1280 | 857,049 | 4.607 |
| Valkey | SET | 8 | 80 | 526,528 | 0.287 |
| Valkey | SET | 8 | 160 | 655,291 | 0.519 |
| Valkey | SET | 8 | 320 | 725,465 | 1.199 |
| Valkey | SET | 8 | 640 | 783,711 | 3.519 |
| Valkey | SET | 8 | 1280 | 802,519 | 4.383 |
| Valkey | GET | 16 | 80 | 544,238 | 0.279 |
| Valkey | GET | 16 | 160 | 692,905 | 0.519 |
| Valkey | GET | 16 | 320 | 826,689 | 1.463 |
| Valkey | GET | 16 | 640 | 897,768 | 3.583 |
| Valkey | GET | 16 | 1280 | 965,697 | 4.543 |
| Valkey | SET | 16 | 80 | 510,893 | 0.295 |
| Valkey | SET | 16 | 160 | 607,620 | 0.527 |
| Valkey | SET | 16 | 320 | 686,303 | 1.015 |
| Valkey | SET | 16 | 640 | 703,116 | 3.423 |
| Valkey | SET | 16 | 1280 | 741,469 | 4.127 |
*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
The tested Valkey configurations keep the dataset in DRAM. Lavik uses a memory key index with SSD value storage while accepting Redis/Valkey-compatible commands over RESP. A protocol match makes existing client investment useful; it does not prove identical behavior for every command and option.
For long-lived sessions, caches and machine-generated feature data, the important question is whether useful capacity must grow at DRAM prices. Lavik makes NVMe SSD the value-capacity tier, then uses asynchronous execution to pursue high throughput without making the entire value set resident in memory.
Lavik beta.1 system architecture ↗ · 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 ↗
Growing capacity need not carry a DRAM price tag
ILLUSTRATIVE MODEL · EDIT THE ASSUMPTIONS
20× lower value-capacity cost starts with the unit price
The defaults assume DRAM at $5/GiB and NVMe SSD at $0.25/GiB: a 20:1 ratio. These are illustrative media prices, not live quotes or monthly cloud instance prices.
DRAM / SSD value-capacity cost ratio
Valkey DRAM: $5,120 · Lavik NVMe SSD: $256
Value-capacity cost = dataset GiB × media price/GiB
This value-capacity model excludes key/index memory, buffers, CPU, network, backups, replicas and operations. A 20× value-capacity difference therefore does not mean a 20× cheaper complete service. Add index memory and shared costs in the full capacity calculator.
When to choose Lavik
Evaluate Lavik when memory is the scaling constraint and your Valkey command/client footprint fits Lavik's versioned compatibility coverage. Compare throughput at your latency budget, then replay expiry, reconnect and failover paths before a staged migration.
When keeping your current system makes sense
Retain Valkey when an existing DRAM-sized workload is economical and its behavior is already proven in your application. In particular, do not trade away a write-latency requirement merely to maximize the headline QPS number.
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
Does higher QPS mean Lavik has lower latency on every operation?
No. In the 10M-key peak results, Lavik leads GET/SET throughput and GET p99, while Valkey has the lower SET p99 at its own peak. Use the full connection sweep to select an operating point that meets your latency budget.
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