LavikPERFORMANCE · ARCHITECTURE · COST
Lavik vs Pika
Disk capacity with substantially more measured throughput.
Lavik vs Pika: 200-million-key NVMe SSD benchmarks for GET, SET and mixed traffic, RocksDB storage differences, and throughput-driven cost estimates.
By the Lavik project · Sources checked: 2026-10-13 · Pika v4.0.3 source tag (binary reports 4.0.2)
AUGUST 2026 · HISTORICAL EXPERIMENT
Performance, with the measurements attached
200M keys with uniformly distributed 1,000–4,000-byte values; the same Azure Standard_L16s_v3 server/client setup, two NVMe devices, 80 connections and 300-second windows. Runs proceed GET → 1:1 mixed → SET without reloading; maintenance and persistence settings differ. Azure Managed Redis rows from a different environment are excluded. Lavik is the historical August build, not beta.1. Method and full report ↗
| Workload | System | QPS | p99 (ms) | p99.9 (ms) | Connections |
|---|---|---|---|---|---|
| GET | Lavik SPDK · August build | 310,387 | 0.455 | 0.895 | 80 |
| GET | Pika v4.0.3 source tag (binary reports 4.0.2) | 86,669 | 1.775 | 2.383 | 80 |
| SET | Lavik SPDK · August build | 392,284 | 0.999 | 1.607 | 80 |
| SET | Pika v4.0.3 source tag (binary reports 4.0.2) | 79,537 | 4.223 | 7.327 | 80 |
| GET:SET 1:1 | Lavik SPDK · August build | 352,442 | 0.631 | 1.447 | 80 |
| GET:SET 1:1 | Pika v4.0.3 source tag (binary reports 4.0.2) | 75,324 | 3.615 | 6.527 | 80 |
What this result does—and does not—establish
The test built official Pika tag v4.0.3; the executable reports 4.0.2. It used 16 network threads, 32 request threads, three RocksDB instances, 24 GiB total block cache and 32 GiB RTC cache. WAL/binlog and compression were disabled; automatic compaction stayed enabled. These choices must accompany any performance claim.
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.
How the storage design affects your application
Pika uses RocksDB to provide Redis-compatible data structures with capacity beyond memory. Lavik also targets Redis-compatible access, but serves its own durable records using an asynchronous storage engine. This comparison is between two disk-capable systems, not SSD capacity versus a mandatory all-DRAM Pika deployment.
When disk capacity is already affordable, throughput per server becomes the next economic constraint. The August results show a Lavik SPDK advantage across read-only, write-only and mixed traffic. That gives a concrete starting point for reducing the number of nodes needed for a fixed request rate.
Pika README at the tested source commit ↗ · 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 | 310,387 / 0.455 ms | 5 / 10 | $10,000 |
| Pika | 86,669 / 1.775 ms | 17 / 34 | $34,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
Evaluate Lavik when broad random reads or mixed traffic are forcing a disk-backed Pika fleet to grow for QPS rather than bytes. Replay real collection commands as well: the published comparison measures string operations, not hash, list or sorted-set performance.
When keeping your current system makes sense
Keep Pika when its existing operational model and compatibility satisfy your requirements and the measured bottleneck does not appear in your workload. Validate migration, replication and recovery semantics before changing a production storage engine.
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
Why can Lavik cost less when Pika already uses SSD?
At the same data size and request-rate target, a higher observed QPS per node can reduce the throughput-driven node count. The calculator assumes usable capacity, node prices and scaling efficiency; it is a sizing illustration, not a measured multi-node cluster result.
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