Lavik 0.2.0 Released: Less Work per Request, More Room for Your Data

Lavik 0.2.0 is here

Lavik 0.2.0 is available for Linux x86-64 and ARM64. This release focuses on the work between a Redis command and an NVMe value: copying fewer bytes, allocating less temporary state, and submitting storage work more efficiently. You keep the Redis-compatible interface while giving growing catalogs, application caches and online state room beyond DRAM.[1][2][3]

Do less work for each object

The 47 commits since 0.1.0 improve both large objects and small point operations. Large String paths remove intermediate receive, staging and read copies. Hash and Set reads avoid decoding whole compact objects, while compact writes splice affected bytes. Sorted Set mutations reuse page capacity and edit encoded pages with fewer per-member allocations. Collection responses use packed, owned byte blocks and batched replies.[2]

The io_uring and SPDK paths now use queued submissions. Grouped reads parallelize work per physical owner, while transaction cleanup is separated from writes and flushes are batched. These changes reduce work in the request path; their value to an application depends on its object sizes, command mix and concurrency.[2]

Current measurements, from compact instances to a billion keys

In the October 21 16-vCPU SPDK comparison, Lavik 0.2.0 reaches 1,156,956 GET QPS at 7.103 ms p99.9 and 945,384 SET QPS at 10.175 ms p99.9. Both points use 1,280 connections, 10 million 1 KiB values, pipeline depth 1 and 30-second windows. The measured Redis 8.10.2 and Valkey 9.1.2 controls use DRAM and disable AOF and scheduled snapshots. The full connection sweep shows the throughput and latency tradeoffs.[5]

For capacity, the 2-vCPU experiment retains 100 million keys containing 95.37 GiB of logical value payload on a nominal 16 GiB host. GET and SET peaks are 215,644 and 231,361 ops/s. On the separate 16-vCPU billion-key experiment, Lavik reaches 1,129,597 GET QPS and 910,356 SET QPS using 32 client threads and 60-second windows. It has the highest full-sweep peaks among the six storage-backed systems; Garnet leads GET at 160 connections. Keys, indexes, replicas and storage headroom remain additional sizing inputs.[5][6]

The refreshed Aerospike YCSB matrix covers 100 million ten-field records and four workload mixes. Lavik has 9.06%–24.08% higher unlimited total throughput, with higher p99.9 in four of seven unlimited operation cells. CPU/IRQ policies and persistence differ. These are results for the recorded deployments, rather than a guarantee for another application or an isolated before/after version comparison.[7]

Integrity policy and correctness fixes

Data-record and value/key extent CRC generation is now disabled by default and selectable at startup with record-crc. Each object keeps its policy, and existing CRCs are still checked. Metadata, checkpoints, function catalogs and replication retain their checks. Older readers cannot consume objects written with the new no-CRC flags; include that format boundary in upgrade and recovery planning.[3][4]

Replication V2 handles wide argument counts, and admitted writes are preserved under memory pressure. The release also retains accepted Admin mutation results and refreshes Stream range locations before pinning. Together with the collection and I/O changes, these fixes make 0.2.0 a useful release to rehearse with a representative cache or online-state dataset.[2]

Start with your application

Download the 0.2.0 archive, verify its SHA-256, and follow the current quick start. Minimal uses kernel TCP/io_uring; Standard includes DPDK/SPDK. Both require Linux 6.1+ with io_uring enabled and Ubuntu 24.04-compatible glibc. The release includes Lavik Admin and its Node.js runtime. Keep your application command mix, retention target and page-level latency budget in the rehearsal, then use the new benchmark reports to understand the matching storage path.[1][3]