Lavik 0.2.0 SPDK vs Redis 8.10.2 and Valkey 9.1.2: 16 vCPUs / 8 physical cores, AMD EPYC 9V74, 128 GiB nominal RAM, six NVMe SSDs, 10 million 1 KiB values, pipeline 1, 30-second windows. Selected peaks use 1,280 connections; Redis uses 16 I/O threads, Valkey GET 16 / SET 8. Latency is p99.9 at the same point. All values come from the archived memtier JSON results. QPS is displayed to the nearest whole operation; p99.9 retains the recorded millisecond precision. Redis/Valkey disable AOF and automatic snapshots. Single-run results do not establish equivalent durability or an application SLA.
For equal value capacity, a 20:1 DRAM/NVMe SSD price per GiB puts Lavik’s value-storage media cost at 5% of DRAM. Redis and Valkey use the same DRAM unit price. The model excludes index and runtime memory, replication, servers and operations. Enter your actual prices in the calculator. Cost methodology ↗
01 / THE STORAGE MODEL
Keep the Redis interface. Grow beyond DRAM.
When your dataset grows, keeping every value in memory gets expensive. Lavik keeps a compact key index in DRAM and places values on NVMe SSD, so more data does not mean buying DRAM for every byte.
>_Your applicationRedis clients · RESP2 / RESP3
→
LAVIK
worker 1worker 2worker 3worker 4
DRAMKey indexLocate your data
→
NVMe SSDValue capacityRoom for your dataset
01
Familiar commands and clients
Use Redis data structures, RESP2/RESP3 clients, and familiar application patterns. Check the commands, client versions, and behaviors your application depends on.
At a 20:1 DRAM-to-NVMe SSD price per GiB, the same value capacity costs 5% as much. Index memory, replication, and shared server costs are additional. Use your prices in the calculator.
Workers process independent requests in parallel. Coroutines overlap I/O with other work. The Standard package includes SPDK storage support—the backend used in the headline benchmark.
The published storage-tier experiment goes beyond the small in-memory comparison: one billion keys with 1 KiB values, on a host with 128 GiB nominal RAM.
Lavik 0.2.0 SPDK · October 21, 2026 · peak GET at 1,280 connections · pipeline=1 · 60-second measurement. One server, six NVMe SSDs.
02 / A SIZING ILLUSTRATION
Imagine 300 nodes becoming 3.
For a cluster expanded to hold more data, higher capacity per node makes a smaller fleet worth evaluating. Start with your capacity needs—and keep your latency target in the acceptance criteria.
300Redis data nodes
→
3Lavik data nodes
Capacity illustration · not a measured migrationEach cube represents one hypothetical data node.
Illustrative Redis capacity300 × 32 GiB
=
Illustrative Lavik capacity3 × 3,200 GiB
Same aggregate value capacity9.38 TiB
Assumes 100× more usable value capacity per Lavik data node. This is capacity arithmetic, not a tested 300-to-3 migration or a recommended topology. The 100× node-count ratio is separate from the 20× capacity-price ratio. Size the DRAM index, CPU, network, replicas, control plane, recovery headroom, and failure domains for the actual deployment.
THE ACCEPTANCE TEST
Set the P99.99 SLA first.
Replay your key sizes, command mix, concurrency, expiration, and persistence settings. Measure tail latency under sustained load, replication, and failover before choosing the final node count.
Start with one capacity-heavy dataset. Load a representative copy with RedisShake, replay application traffic, and compare node count at the same retention and response-time targets. Keep headroom for replicas and recovery before cutting over.
One account can drive many agents, each with its own profile, session context, and feature state. Keeping that expanding state addressable should not force every value into expensive memory.
Lavik gives these applications Redis-compatible key-value building blocks with NVMe SSD value capacity. Your application controls retention, access boundaries, and how agent state is represented.
A CAPACITY PLANNING EXAMPLE
1Maccounts×100agents / account=100Magent state records
1200
5.96 TiB
100× the baseline value capacity, at the same record size.
Assumes 1 million accounts and 64 KiB per state record. One record per account is 61.04 GiB. This is an adjustable planning scenario, not a forecast for every agent application. Index, replication, and runtime overhead are additional.
PROFILE / CONTEXT
Profiles that multiply
Store agent preferences, task context, and per-session state as application-defined keys and hashes.
We are committed to building Lavik as an open-source project under Apache 2.0. Read the code, use it in your projects, and help shape what comes next.
Lavik 0.2.0 is available now. The code, benchmark procedures and architecture documents are public. Build with it, inspect how it works, and help us make it better.
Lavik