Lavik 0.1.0 Released: Faster Than Redis on DRAM, With Values on NVMe SSD

Lavik 0.1.0 is here. Our first stable release brings Redis-compatible key-value storage on NVMe SSD, major big-key optimizations, and a more complete path from first deployment to day-to-day operations. It builds on a simple result from our published benchmark: Lavik with values on NVMe SSD achieved higher peak GET and SET throughput than the tested Redis and Valkey configurations with their datasets in DRAM.

The goal is practical: keep using familiar Redis data structures and clients as your dataset grows, without making DRAM the home of every value. Lavik retains a compact key index in memory and puts values on storage. Version 0.1.0 makes that foundation more useful for large strings, growing collections, stream workloads, and managed deployments. Lavik remains open source under Apache 2.0.

Fast on NVMe SSD: the published numbers

The performance foundation is the September 18 SPDK comparison, which tested the downloadable Lavik 0.1.0-beta.1 package. For 10 million keys with 1 KiB values, Lavik reached 1,012,180 GET requests per second at 3.599 ms p99. Redis 8.8.0 reached 976,801 at 4.671 ms p99; Valkey 9.1.0 reached 965,697 at 4.543 ms p99. For SET, the respective peaks were 930,465, 910,426, and 802,519 requests per second.

The larger dataset is where the capacity argument becomes concrete. At one billion keys with 1 KiB values, Lavik SPDK reached 952,560 GET requests per second at 3.599 ms p99. Dragonfly 1.40.2 Tiered Storage reached 466,039 at 38.911 ms p99, and Garnet 2.1.5 with its storage tier reached 446,366 at 4.223 ms p99. Lavik had the highest measured peak GET and SET throughput among those three tested storage-backed configurations. For this report’s large-dataset GET workload, it was also the lowest-p99 system at the selected peaks.

These are measured results for the beta.1 build, not a new benchmark of the stable binary or of its big-key changes. The report used pipeline 1, uniform random GET or overwriting SET, 16-CPU affinity, and fresh SPDK datasets on six NVMe devices. Peaks use each product’s selected connection count and thread configuration; peer-control measurements were reused from an earlier sweep on the same hosts. The report also discloses Garnet’s omitted post-test exact key count. SET latency rankings differ from GET, and the report does not establish equivalent crash durability. Use the complete report to reproduce the workload and compare the latency percentile your application needs.

Big keys deserve a storage design, not just a larger memory budget

A large Redis key may be a multi-megabyte string, a hash with many fields, a long list, a sorted set, or a stream with consumer state. Their access patterns differ: reading a short range is different from reading the whole object, and changing one field is different from replacing every field. Lavik 0.1.0 develops its grouped storage around those distinctions across String, Hash, Set, List, Sorted Set, and Stream.

Large strings now use fixed 8 KiB byte segments. Range operations can address the relevant segments, while small strings retain a compact representation. The design gives a small range read or partial update a more focused storage path instead of requiring every operation to treat the entire large value as one unit. Whole-value requests still have to transfer the requested bytes; segmentation does not make a huge GET response free.

Collections grow into independently addressed groups with an 8 KiB target. Compact values promote at 16 KiB of encoded size; complete updates can compact them again when active primary group payloads fall below 8 KiB. Those sizes are representation rules, not universal hard limits: an indivisible entry or a hash collision can exceed the group target. Long keys share an immutable key record referenced by UUID, reducing repetition across the object’s records.

The same release improves Hash/Set point-write allocation and lookup work, Sorted Set routing and RESTORE construction, and the overlap of List/Stream range reads. Streams use grouped logical records. Together, these changes focus work on the parts of a collection that an operation actually needs, while retaining the ordering and lifetime rules needed by concurrent readers, replication, and recovery.

Redis-compatible development, with clearer deployment modes

Lavik speaks RESP2 and RESP3. The stable release expands managed Single mode to all 16 logical databases and cross-slot multi-key operations. Its managed command handling includes transactions, Lua and Functions, Stream reads, SORT_RO, and RDB saves. Cluster mode retains DB0 and same-slot constraints, so choose the mode against the commands and client behavior your application actually uses.

Moving an existing application also needs a practical data path. The release documents RedisShake v4.6.2 import from Redis or Redis Cluster into a fresh managed Lavik target: baseline copy, incremental catch-up, a final write pause, and verification before cutover. Source and target shard counts need not match. The website’s combined From Redis guide now includes the configurations and steps directly on the page.

Operations are part of the release

The Linux release archives now bundle Lavik Admin and its Node.js runtime alongside lavik, lavik-meta, and lavik-ctl. Admin provides a deployment and management interface for the database: SSH host preparation, version selection, node placement, deployment progress, topology management, and monitoring setup. The UI and CLI share a workspace and operation records, making the same deployment accessible through either interface.

Meta moves to an asynchronous etcd Raft runtime with an explicit RAFT identity, WAL, and snapshot state. Data nodes take their Single or Cluster client mode from the committed Meta manifest. The release also adds Sentinel-compatible discovery for managed Single deployments, with independent authentication, TLS, and advertised hostnames, and improves replica startup and full-transfer handling. These capabilities make deployment and discovery more complete; application availability still depends on the topology and failure behavior you configure and rehearse.

Make SSD capacity useful to growing applications

Session records, application caches, feature data, and agent state can grow faster than the application’s request rate. With Lavik, value growth can consume NVMe SSD capacity while DRAM remains available for the index and serving work. That changes the capacity-planning question from keeping every value resident in memory to sizing the index, storage headroom, I/O, CPU, and recovery path together.

Big-key improvements make that trade more useful for structured workloads, but good sizing still matters. The key index needs memory; storage needs reclamation and free-space reserves; large replies consume network and client buffers. Rehearse your real key-size distribution, read/write mix, expiration behavior, and recovery requirements rather than extrapolating a single throughput number to every workload.

Start with Lavik 0.1.0

Download a Linux AMD64 or ARM64 archive in Minimal or Standard form from our Download page. The release archives include the bundled Lavik Admin UI and Node.js runtime. Start with the 0.1.0 documentation and choose the installation path that fits your environment.

If you are moving from beta.1, read the upgrade notes before changing binaries. Meta persistence and Data startup flags changed; use matching 0.1.0 Data, Meta, and ctl binaries, retain backups, and rehearse a fresh stable deployment with verified logical data transfer. Do not assume mixed-version rolling upgrades or automatic conversion of beta state.

Lavik is Apache 2.0 because we want developers to use it, examine how it works, and improve it with us. Download the release, put a representative workload on NVMe SSD, and share what you find. The full release notes and getting-started guides are linked below.