Lavik beta: SPDK performance and capacity economics

If DRAM capacity drives your key-value service budget, evaluate measured throughput and modeled capacity savings separately. The September 18, 2026 SPDK report tested the downloaded standard x86_64 v0.1.0-beta.1 package, revision 3955b98d43b312324aa8d52775df52cfb111c0d0—not a rebuild. This remains a beta prerelease, not a stable release. Here we examine its 10M-key Redis/Valkey comparison.

Lavik keeps a compact key index in DRAM and stores values on files, raw block devices, or SPDK NVMe namespaces.

Read the peaks with their conditions

The server had an AMD EPYC 9V74, 8 physical cores/16 logical CPUs, approximately 126 GiB RAM and six NVMe drives. A separate memtier 2.5.1 client used 16 threads, pipeline 1, no rate limit, 10M keys and 1,024-byte values. Uniform random GET and overwriting SET used correlated client seeds, sweeping 80–1,280 connections. Each point ran once for 30 seconds; configurations received 10-second GET warmups.

Lavik used fresh SPDK data, kernel TCP, 16 workers, 8 GiB hugepages, completion cap 16, defragmentation enabled and Tomb Raider disabled. Redis/Valkey disabled AOF and automatic snapshots. Selected peer configurations used 16 I/O threads except Valkey SET, which used eight; these are different thread roles.

Peer controls were reused from an earlier sweep on the same hosts, not newly measured alongside the beta. Products ran sequentially, not interleaved, so temporal variation limits causal conclusions. These are not the September 6 io_uring results.

Peak GET, at CSV precision: Lavik SPDK 1,012,179.91 QPS, p99 3.599 ms, at 640 connections; Redis 8.8.0 976,800.89 QPS, p99 4.671 ms; Valkey 9.1.0 965,696.86 QPS, p99 4.543 ms. Both peers peaked at 1,280 connections.

Peak SET, all at 1,280 connections: Lavik SPDK 930,464.99 QPS, p99 4.799 ms; Redis 910,426.33 QPS, p99 4.831 ms; Valkey 802,519.39 QPS, p99 4.383 ms.

Lavik leads these throughput peaks, not every latency comparison. At 1,280 connections, its GET drops to 940,713.30 QPS with 9.791 ms p99. Peak-to-peak latency is not matched-concurrency latency; inspect the full curves before choosing an operating point.

Verify functionality separately

The September 20, 2026 execution record below passed on the pinned x86_64 minimal beta package. Its platform is x86_64, and artifact SHA-256 8a3e66f313e7…daa77 matches the pinned x86_64 minimal archive. The release, source revision, recipe hash e473c28b9da9… and harness hash ad785c9b0633… also match the pins. The five actual replies were PONG, OK, “hello from Lavik”, 1 and Ada.

The registered recipe block includes verification/start.sh and all five commands. Use it only with a private, disposable instance. Minimal excludes SPDK: this file-backed functional smoke test does not reproduce the published standard-package benchmark.

set -euo pipefail
mkdir -p /tmp/lavik-example
fallocate -l 512M /tmp/lavik-example/data
exec lavik --bind 127.0.0.1 --port 6379 --metrics-port 0 \
  --threads 2 --no-pin-workers --registered-buffer-mb-per-worker 64 \
  --shutdown-checkpoint --data-file /tmp/lavik-example/data \
  --log-dir /tmp/lavik-example/logs

$ redis-cli --raw PING
PONG

$ redis-cli --raw SET greeting 'hello from Lavik'
OK

$ redis-cli --raw GET greeting
hello from Lavik

$ redis-cli --raw HSET user:42 name Ada
1

$ redis-cli --raw HGET user:42 name
Ada

{
  "recipeId": "basic-commands",
  "platform": "Linux-6.17.0-1022-azure-x86_64-with-glibc2.39",
  "steps": [
    {
      "argv": [
        "redis-cli",
        "--raw",
        "PING"
      ],
      "expected": "PONG",
      "actual": "PONG"
    },
    {
      "argv": [
        "redis-cli",
        "--raw",
        "SET",
        "greeting",
        "hello from Lavik"
      ],
      "expected": "OK",
      "actual": "OK"
    },
    {
      "argv": [
        "redis-cli",
        "--raw",
        "GET",
        "greeting"
      ],
      "expected": "hello from Lavik",
      "actual": "hello from Lavik"
    },
    {
      "argv": [
        "redis-cli",
        "--raw",
        "HSET",
        "user:42",
        "name",
        "Ada"
      ],
      "expected": "1",
      "actual": "1"
    },
    {
      "argv": [
        "redis-cli",
        "--raw",
        "HGET",
        "user:42",
        "name"
      ],
      "expected": "Ada",
      "actual": "Ada"
    }
  ],
  "status": "passed",
  "binaryVersion": "lavik 0.1.0-beta.1",
  "sourceCommit": "3955b98d43b312324aa8d52775df52cfb111c0d0",
  "packageVersion": "v0.1.0-beta.1",
  "gracefulRestart": "passed"
}

A successful write response is not a synchronous fsync fence. Evaluate durability, replication, and recovery requirements for your workload.

Model a subtotal, not deployment-wide savings

Assume DRAM costs 20 and SSD 1 currency unit/GiB-month: a hypothetical 20:1 ratio gives 95% savings on payload capacity alone, not a sourced quote. The calculator below normalizes to 1 GiB and defaults to 2% index RAM, identical shared costs equal to 10% of Redis payload-memory cost, equal replica counts, no compression and storage amplification 1. Its “Lavik memory / payload capacity” slider models index RAM—not total RAM or measured usage.

Scaling those assumptions to 1,024 GiB, the checked monthly calculation is Redis: 20,480 + 2,048 = 22,528 units; Lavik: 1,024 + 409.60 + 2,048 = 3,481.60 units. That is an 84.55% saving on the modeled subtotal and a 6.47:1 cost ratio; the calculator displays savings rounded to 84.5%. Runtime/buffer RAM and SPDK’s separate 8 GiB reservation are unpriced. The shared allowance does not specify CPU or operations coverage. This is not a whole-deployment result.

From these defaults, larger indexes, greater storage amplification and higher equal shared costs reduce modeled percentage savings. Next, test your command mix, value sizes, matched offered load, sustained maintenance, recovery and failover; then price the same service boundary. Neither the benchmark nor this calculation establishes unchanged latency, durability or availability.