LavikPERFORMANCE · ARCHITECTURE · COST
Lavik vs Apache Kvrocks
Redis data on disk. More QPS per measured server.
Lavik vs Apache Kvrocks: measured NVMe SSD throughput and p99, Redis data structures on disk, maintenance tradeoffs, and a node-count cost model.
By the Lavik project · Sources checked: 2026-10-13 · Apache Kvrocks 2.16.0 · RocksDB / BlobDB
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 | Apache Kvrocks 2.16.0 · RocksDB / BlobDB | 70,672 | 2.479 | 3.407 | 80 |
| SET | Lavik SPDK · August build | 392,284 | 0.999 | 1.607 | 80 |
| SET | Apache Kvrocks 2.16.0 · RocksDB / BlobDB | 110,167 | 1.759 | 2.671 | 80 |
| GET:SET 1:1 | Lavik SPDK · August build | 352,442 | 0.631 | 1.447 | 80 |
| GET:SET 1:1 | Apache Kvrocks 2.16.0 · RocksDB / BlobDB | 88,084 | 2.207 | 4.927 | 80 |
What this result does—and does not—establish
Kvrocks used 16 workers, an 80 GiB block cache, BlobDB and RAID0/XFS. WAL, per-write sync, compression and Blob GC were disabled; ordinary flush and automatic compaction remained enabled. Disabling those durability/maintenance features changes the operational contract. Do not interpret the result as equal durability or sustained long-term space reclamation.
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
Kvrocks encodes Redis data structures into RocksDB keys and column families. Lavik uses its own record and collection representations with memory indexes and asynchronous storage. Both can move substantial value capacity away from DRAM; Lavik's differentiator here is measured service rate and tail latency.
Collection support is not unique to Lavik: Kvrocks documents hashes, lists, sets and sorted sets on RocksDB. The engineering choice is how each representation behaves under your read/update mix, cache budget and background maintenance. The table below measures identical string workloads on the same local hardware.
Apache Kvrocks data structures on RocksDB ↗ · 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 |
| Apache Kvrocks | 70,672 / 2.479 ms | 21 / 42 | $42,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 SSD is already the right capacity medium but random-read latency or QPS is limiting your Kvrocks deployment. Include overwrite churn and disk-space recovery in a longer test so the node savings survive steady-state operation.
When keeping your current system makes sense
Retain Kvrocks when its RocksDB-based operating model, commands and existing tooling fit your application and your latency target is already met. Budget the migration around real command semantics and recovery behavior, not only a GET chart.
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 Kvrocks just an in-memory database with a disk cache?
No. Apache Kvrocks uses RocksDB as its storage engine and maps Redis data structures onto it. Lavik is an alternative disk-capable architecture; this comparison evaluates throughput and latency, not whether only one system can store collections on disk.
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