LavikPERFORMANCE · ARCHITECTURE · COST
Lavik vs Garnet
A stronger read result. A real write-latency tradeoff.
Lavik vs Microsoft Garnet: NVMe SSD GET throughput, honest SET latency tradeoffs, Tsavorite storage differences, and an editable node-cost model.
By the Lavik project · Sources checked: 2026-10-13 · Garnet 2.1.5 · Libaio Storage Tier
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 | Garnet 2.1.5 · Libaio Storage Tier | 446,366 | 4.223 | 9.151 | 320 |
| SET | Lavik 0.1.0-beta.1 SPDK | 764,939 | 10.879 | 16.639 | 1280 |
| SET | Garnet 2.1.5 · Libaio Storage Tier | 751,057 | 5.535 | 12.735 | 1280 |
What this result does—and does not—establish
Garnet's peak SET p99 is 5.535 ms versus Lavik's 10.879 ms. At a p99 ceiling of 2 ms, the best observed SET points are about 584,665 QPS for Garnet and 422,450 for Lavik. Garnet's post-test full key-count scan was not completed; the report discloses that limitation. Its pre-test count passed.
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 |
| Garnet | GET | 16 | 80 | 218,677 | 2.543 |
| Garnet | GET | 16 | 160 | 393,828 | 3.071 |
| Garnet | GET | 16 | 320 | 446,366 | 4.223 |
| Garnet | GET | 16 | 640 | 404,276 | 5.471 |
| Garnet | GET | 16 | 1280 | 398,503 | 7.583 |
| Garnet | GET | 16 | 2560 | 352,533 | 15.039 |
| Garnet | SET | 16 | 80 | 424,072 | 1.415 |
| Garnet | SET | 16 | 160 | 584,665 | 1.431 |
| Garnet | SET | 16 | 320 | 701,687 | 2.719 |
| Garnet | SET | 16 | 640 | 737,526 | 4.031 |
| Garnet | SET | 16 | 1280 | 751,057 | 5.535 |
| Garnet | SET | 16 | 2560 | 720,740 | 9.087 |
*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
Garnet uses the Tsavorite hybrid log, with a memory-resident portion and a larger-than-memory storage tier. Lavik uses memory key indexes and its own durable record/collection storage, with SPDK or io_uring I/O. Both offer Redis-style data structures; Garnet should not be described as a string-only database.
The billion-key results make Lavik particularly interesting for read-heavy services: feature retrieval, large caches and profile lookups. A high-rate write service needs a different decision. Garnet's write tail can be lower even when Lavik records slightly more peak SET throughput.
Garnet features and Tsavorite storage ↗ · 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 |
| Garnet | 446,366 / 4.223 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
Start with Lavik for broad-access, read-dominated workloads whose data exceeds RAM. Use the measured GET advantage to evaluate capacity per server, then include updates, expirations and sustained maintenance in your replay.
When keeping your current system makes sense
Keep Garnet on the shortlist for a write-heavy workload with a tight p99 limit, or if your application depends on its .NET extensibility. The cost calculator can select SET and a 2 ms ceiling so this tradeoff is visible rather than hidden by peak GET numbers.
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
Is Lavik always faster than Garnet?
No. Lavik has the higher peak GET and SET throughput in the September billion-key report, but Garnet has lower p99 at its peak SET point and more qualifying SET throughput under a 2 ms p99 ceiling. Compare the workload and latency target together.
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