LAVIK / BLOG
How Lavik works, what we are building, and how to put NVMe SSD capacity to work in your applications.
Lavik 0.2.0 is here → · Latest performance reports →
FEATURED · IN DEPTH
Why keep buying servers for RAM? Lavik combines NVMe SSD capacity with throughput above Redis on DRAM. Explore the architecture, benchmarks and economics of a 300-to-3 consolidation.
Read the article
An NVMe-backed activity history can outgrow RAM while its API still returns small pages. Evaluate Redis client compatibility at the response boundary: decoding, range semantics, cancellation, and slow consumers.
A hypothetical image-processing queue shows why replay retention, pending deliveries, and physical storage need separate budgets—and how Lavik’s NVMe-backed Streams support that design.
A catalog refresh must remove obsolete fields as well as update values. Use that application contract to guide a first Lavik evaluation, with package and storage choices supporting the design.
A migration can copy every value correctly and still keep stale data alive too long. Use a TTL-sensitive cache to define compatibility, expiry validation, latency acceptance, and a clean fallback.
A packed timeline cache shows how Lavik’s NVMe values and segmented Strings can support larger objects while keeping selected reads and updates local.
Leaner String and collection paths, queued I/O, replication fixes, and new benchmarks from 2 vCPUs to a billion keys. Start with the 0.2.0 packages and versioned docs.
A hypothetical page-rendering service shows how command fan-out, response bytes, independent arrivals, and background refreshes change the meaning of Lavik’s benchmark throughput.
Our first stable release brings Redis-compatible storage on NVMe SSD, 8 KiB segments for large strings, improved collections, bundled Lavik Admin, and a more capable managed deployment.
Keep your Redis client while moving value capacity to NVMe SSD. Choose the right routing mode, initialize pooled connections consistently, and size concurrency for the application.
A growing Lavik cache needs a capacity budget per worker as well as per server. A hypothetical uneven key distribution shows why spare NVMe space and aggregate memory headroom may not admit the next key.
A storage quote becomes useful only after accounting for replicas, physical overhead, index memory, and room to rebuild. Compare configurations that meet the same operating requirements.
Minimal and Standard define different deployment prerequisites. Start with the package that answers your first evaluation question, then treat SPDK as a separate experiment.
A migration rehearsal should prove what happens after Lavik accepts new writes: how to validate the data, judge latency, and return to the source without silently losing changes.
Moving reconstructable session context to SSD changes the capacity budget. TTL visibility, index removal, physical reclamation, and authoritative login state still need separate decisions.
Growing cached objects changes more than capacity. A hypothetical payload expansion shows how Lavik shifts pressure toward response bytes, replacement writes, and storage reclamation.
Lavik’s September 18 SPDK sweep shows why the highest-throughput point may be the wrong operating point. A latency-constrained reading reveals a different comparison.
A practical compatibility checklist for Lavik: verify replies, connection state, errors, and what your client does when the first attempt has no clear outcome.
A worked capacity model shows why moving values to NVMe changes the budget without removing index memory, reclamation headroom, or shared server costs.
Understand the September 18 benchmark, verify basic commands, and model capacity savings without mistaking them for deployment-wide savings.
Key ownership makes local work efficient. Multi-key commands need a separate design for scheduling, lock lifetime, command errors, and durable completion.
Lavik’s control-plane decisions distinguish a planned handoff from owner loss. Follow the state transitions that prevent stale preparation and observations from becoming authority.
Lavik treats a shutdown checkpoint as a one-use recovery accelerator. Its publication, consumption, and fallback rules are the substance of the design.
Large hashes, lists, sets, and sorted sets need more than a place to store one giant value. Lavik uses collection-specific routing and atomic graph publication.
An SSD-backed Redis interface needs more than asynchronous reads. Follow a request through connection state, admission, partition ownership, and reply backpressure.
Lavik tracks native replication by history and logical flow. Understand what an acknowledgement proves, what a restart discards, and why failover needs additional evidence.
A function library must become consistent across workers, survive restart, and travel through replication. Lavik stages complete catalogs before making them visible.
Follow the ownership, append, read, and reclamation decisions behind a value store that can grow beyond DRAM capacity.
Read the measured results, their conditions, and the questions they leave open.
Lavik