LavikPERFORMANCE · ARCHITECTURE · COST
Lavik vs Tendis
Higher measured throughput for a disk-backed Redis workload.
Lavik vs Tencent Tendis: NVMe SSD read/write benchmarks, RocksDB and native storage differences, cluster evaluation criteria, and cost assumptions.
By the Lavik project · Sources checked: 2026-10-13 · Tendis 2.8.4-rocksdb-v8.5.3
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 | Tendis 2.8.4-rocksdb-v8.5.3 | 68,860 | 2.063 | 5.855 | 80 |
| SET | Lavik SPDK · August build | 392,284 | 0.999 | 1.607 | 80 |
| SET | Tendis 2.8.4-rocksdb-v8.5.3 | 160,642 | 1.335 | 2.127 | 80 |
| GET:SET 1:1 | Lavik SPDK · August build | 352,442 | 0.631 | 1.447 | 80 |
| GET:SET 1:1 | Tendis 2.8.4-rocksdb-v8.5.3 | 102,213 | 1.439 | 1.975 | 80 |
What this result does—and does not—establish
The Tendis run used ten RocksDB stores sharing a 72 GiB block/blob cache. WAL, binlog, per-transaction log flush and compression were disabled; automatic compaction and Blob GC stayed enabled. No additional warmup or compaction wait was added after loading. Cluster membership and failover were not benchmarked.
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
The tested open-source Tendis server stores data through RocksDB and exposes a Redis-compatible interface. Its repository also describes use within Tendis Hybrid Storage Edition; this benchmark measures the specific standalone Tendis binary, not that complete hybrid deployment or a managed cloud service.
Both designs aim to escape DRAM capacity limits. Lavik's measured QPS advantage matters when enough SSD bytes are available but your cluster still needs more servers to handle reads and writes. Higher per-node capacity to serve requests can change the budget even if both products use identical SSD prices.
Tendis 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 |
| Tendis | 68,860 / 2.063 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 for a large, broadly accessed dataset when serving rate determines the size of your Tendis fleet. In addition to the data-plane benchmark, exercise client routing, replica recovery and failure handling with the documented Lavik deployment model.
When keeping your current system makes sense
Keep Tendis when its established cluster behavior and operational tooling are central to your system and the throughput target is already satisfied. A single-server benchmark cannot establish that two products have interchangeable failover semantics.
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 the Tendis comparison prove fewer Lavik nodes meet the same SLA?
It supplies measured single-server QPS and latency. The node estimate assumes balanced sharding, linear scaling and explicit capacity/headroom. It does not establish cluster failure behavior, equal crash durability, or an application P99.99 SLA.
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