LavikPERFORMANCE · ARCHITECTURE · COST
Lavik vs KeyDB
When the working set is too broad for the hot tier.
Lavik vs KeyDB On Flash: uniform-access SSD benchmark results, the importance of hot-set locality, experimental feature scope, and transparent cost modeling.
By the Lavik project · Sources checked: 2026-10-13 · KeyDB 6.3.4 · On Flash (experimental)
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 | KeyDB 6.3.4 · On Flash (experimental) | 6,146 | 18.047 | 25.471 | 80 |
| SET | Lavik SPDK · August build | 392,284 | 0.999 | 1.607 | 80 |
| SET | KeyDB 6.3.4 · On Flash (experimental) | 5,395 | 24.447 | 31.359 | 80 |
| GET:SET 1:1 | Lavik SPDK · August build | 352,442 | 0.631 | 1.447 | 80 |
| GET:SET 1:1 | KeyDB 6.3.4 · On Flash (experimental) | 5,197 | 29.311 | 39.167 | 80 |
What this result does—and does not—establish
The report explicitly says this access pattern differs from KeyDB On Flash's recommended hot-key workload. KeyDB retained its RocksDB WAL and automatic compaction, while some other controls disabled WAL. It used four server threads, with no extra warmup or background-organization wait. The very large ratio belongs to this configuration and distribution only.
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
KeyDB On Flash is a RocksDB-backed feature that retains hot data in DRAM and can stream larger values from flash. Its documentation labels it beta/experimental. The measured configuration used a 64 GiB hot tier with allkeys-lru. This page compares On Flash, not ordinary in-memory KeyDB performance.
Uniform random access across 200 million keys makes a small hot tier less effective. That is a useful stress case for long-tail caches, broad feature retrieval and machine-generated profiles. Lavik's stronger result in this case is a reason to test it when locality is weak, not a claim that all KeyDB applications behave this way.
KeyDB On Flash documentation ↗ · KeyDB On Flash sizing and workload guidance ↗ · 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 |
| KeyDB | 6,146 / 18.047 ms | 233 / 466 | $466,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
Prioritize Lavik when a broad active keyspace prevents a DRAM hot tier from absorbing most requests. Model the node-count implication, then validate with both your actual popularity distribution and a cold-start or cache-churn interval.
When keeping your current system makes sense
Retain KeyDB On Flash as a candidate when a small, stable hot set dominates traffic and its experimental status fits your deployment requirements. The uniform benchmark deliberately removes that locality advantage, so a production-like replay is essential.
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 this mean KeyDB itself is always much slower?
No. These numbers concern KeyDB 6.3.4 On Flash with a 64 GiB hot tier and uniform access over 200 million keys. They do not rank in-memory KeyDB or a hot-key-heavy workload. Cost estimates inherit that same limitation.
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