LavikCOMPARE LAVIK
SSD capacity economics. Throughput beyond the DRAM controls.
In the September SPDK test, Lavik on NVMe SSD records higher peak GET and SET QPS than Redis and Valkey in DRAM. Compare storage design, tail latency and cost for the workload you actually run.
At a 20:1 DRAM/SSD unit-capacity price ratio, value-capacity cost falls to one twentieth. Against other SSD-backed products, the next question is how much throughput each node can deliver. Full September report ↗
Compare with your current stack
SEPTEMBER · DRAM CONTROL
Lavik vs Redis
Faster measured throughput. Capacity beyond DRAM.
1.04× GET throughputAt each system’s peak; not all workloads or SLAs.
SEPTEMBER · DRAM CONTROL
Lavik vs Valkey
Keep the protocol. Change the economics of capacity.
1.05× GET throughputAt each system’s peak; not all workloads or SLAs.
SEPTEMBER · BILLION KEYS
Lavik vs DragonflyDB
Billion-key reads without the same tail-latency penalty.
2.04× GET throughputAt each system’s peak; not all workloads or SLAs.
SEPTEMBER · BILLION KEYS
Lavik vs Garnet
A stronger read result. A real write-latency tradeoff.
2.13× GET throughputAt each system’s peak; not all workloads or SLAs.
AUGUST · HISTORICAL DISK TEST
Lavik vs Pika
Disk capacity with substantially more measured throughput.
3.58× GET throughputSame 80 connections, 200M keys; historical Lavik build.
AUGUST · HISTORICAL DISK TEST
Lavik vs Apache Kvrocks
Redis data on disk. More QPS per measured server.
4.39× GET throughputSame 80 connections, 200M keys; historical Lavik build.
AUGUST · HISTORICAL DISK TEST
Lavik vs Tendis
Higher measured throughput for a disk-backed Redis workload.
4.51× GET throughputSame 80 connections, 200M keys; historical Lavik build.
AUGUST · HISTORICAL DISK TEST
Lavik vs KeyDB
When the working set is too broad for the hot tier.
50.50× GET throughputSame 80 connections, 200M keys; historical Lavik build.
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 ↗
Compare experiments without mixing their numbers
10M keys · Redis / Valkey
September 18: 1 KiB values, 30-second windows. Lavik beta.1 SPDK versus in-memory controls. Persistence settings and peak connection counts differ.
1B keys · Dragonfly / Garnet
September 18: 1 KiB values, 60-second windows, six NVMe devices. Inspect all connection points and p99 conditions; peak throughput is not an SLA.
200M keys · Disk-backed peers
August 11–12: 1,000–4,000-byte values, 300-second windows, 80 connections, two NVMe devices. Historical builds, not a beta.1 retest.
September method and raw data ↗ · August method and raw data ↗