@nuskey8: We've released lkv, a new embedded DB implementation in Rust. It's a lightweight KVS specialized for Point Lookup, achi…
Summary
nuskey8 released lkv, a lightweight embedded key-value store in Rust optimized for point lookups, claiming ~165x faster than SQLite and ~15x faster than LMDB with a minimal feature set.
View Cached Full Text
Cached at: 08/11/26, 05:42 AM
We’ve released lkv, a new embedded DB implementation in Rust. It’s a lightweight KVS specialized for Point Lookup, achieving high read performance by significantly limiting its features. Compared to SQLite’s default settings, it delivers about 165 times the speed, and about 15 times the speed compared to LMDB. ■Repository https://github.com/nuskey8/lkv
nuskey8/lkv
Source: https://github.com/nuskey8/lkv
lkv
A lightweight and fast embedded key-value store for Rust.

Overview
lkv is a lightweight and fast embedded database implemented in Rust. It is designed specifically for read performance based on hash tables and memory efficiency, featuring faster lookups than LMDB, sled, redb, and others.
To maintain structural simplicity and read performance, lkv comes with a very limited set of features. Here is what lkv supports:
- Writing and reading arbitrary byte sequences
[u8]as Key/Value - Fast, unordered scans
- Fast and zero-copy lookups
- Transactions
- Snapshots
- Explicit compaction
On the other hand, the following features are not supported:
- Reading and writing from multiple processes
- Multiple writers
- Advanced queries such as ranged or prefix queries
- Automatic compaction
Due to its performance characteristics, it is suitable for lightweight configuration persistence or managing master data that rarely changes. Conversely, using it as a general-purpose database with frequent updates is not recommended.
Much of lkv’s design is inspired by LinkedIn’s PalDB and Bitcask. In addition, some ideas are based on FASTER.
For details, refer to docs/design.md.
Installation
cargo add lkv
Quick Start
use lkv::{Database, Result};
fn main() -> Result<()> {
let mut db = Database::create("./example.lkv")?;
let mut write = db.begin_write()?;
write.put("name", "lkv")?;
write.commit()?;
let read = db.begin_read()?;
assert_eq!(read.get("name")?, Some(b"lkv".as_slice()));
for item in read.iter()? {
let (key, value) = item?;
println!("{} = {}",
String::from_utf8_lossy(key),
String::from_utf8_lossy(value));
}
drop(read);
Ok(())
}
Snapshots
When writing to the database using WriteTransaction in lkv, you cannot perform reads at the same time. If you want to read from the database during a write, you can create a snapshot with snapshot() and read through it.
let snapshot = db.snapshot()?;
let old_value = snapshot.get("key")?;
for item in snapshot.iter()? {
let (key, value) = item?;
}
Compaction
Updates to lkv are appended to the Overlay located behind the Base. As updates and deletions increase, old records remain within the file, and the Overlay index also consumes memory.
compact() rebuilds the Base with valid Key/Values, deletes the Overlay and older generations, and physically shrinks the database file.
// Ensure no snapshots are referenced during compaction
drop(snapshot);
db.compact()?;
Compaction is not performed automatically. If the Overlay exceeds the configured memory limit, new WriteTransactions will return Error::MaintenanceRequired.
During compaction, a backup Base is constructed at the end of the same file, so additional disk space is required until completion. In the event of a crash, recovery is possible from the synchronized Base upon reopening, though the file reduction may not be complete. In such cases, compact() can be run again.
In-Memory
It is also possible to use lkv as an in-memory database.
let mut db = Database::memory();
The API is identical to that of a regular database, but it operates in memory without creating a file.
Benchmark
The benchmarks were conducted using a MacBook Pro with an Apple M2 chip and 24 GB of RAM.
| DB | Bulk 100k (ms) | Write 1 (ms) | Write 1k (ms) | Read 100k (ms) | Delete 1 (ms) | Size (MiB) | Size compacted (MiB) |
|---|---|---|---|---|---|---|---|
std::HashMap | 11.48 | N/A | N/A | 2.74 | N/A | N/A | N/A |
| lkv | 79.94 | 4.70 | 6.43 | 3.29 | 4.94 | 29.17 | 9.44 |
| redb | 169.36 | 4.98 | 7.14 | 38.24 | 5.12 | 128.50 | 16.70 |
| LMDB (heed) | 56.79 | 5.40 | 6.19 | 50.12 | 5.08 | 36.13 | 9.10 |
| RocksDB | 65.23 | 5.40 | 6.89 | 77.89 | 5.22 | 10.07 | 10.07 |
| Fjall | 168.25 | 4.23 | 5.71 | 71.05 | 4.97 | 73.80 | N/A |
| sled | 686.08 | 4.45 | 13.05 | 55.13 | 5.79 | 80.18 | N/A |
| SQLite (rusqlite) | 98.80 | 0.34 | 1.35 | 545.17 | 0.43 | 21.39 | 10.51 |
| jammdb | 132.79 | 5.23 | 9.85 | 72.07 | 5.45 | 64.50 | N/A |
License
Similar Articles
Noxu DB, a Rust port of Berkeley DB Java Edition
Noxu DB is an embedded transactional key-value database engine written in Rust, ported from Berkeley DB Java Edition, offering ACID transactions, B+tree storage, crash recovery, and optional replication.
proveKV – Honest 36× lossless (vs f32, 18x vs fp16) KV‑cache compression for LLMs (zero PPL regression)
An open-source repo, proveKV, demonstrates a reproducible KV-cache compression technique achieving 36x lossless (vs f32) and 68x lossy memory reduction on SmolLM2-1.7B with zero PPL regression, including Rust examples and an audit pipeline.
DKV: Open-source KV-cache compression framework for local LLM inference (CLI + technical report)
DKV is an open-source framework for compressing KV-cache during local LLM inference, providing a CLI and a technical report.
@davideciffa: Very proud to share that we just release Luce KVFlash. Run your preferred model inside Lucebox at 256k context, without…
Announced release of Luce KVFlash, a tool to run models inside Lucebox at 256k context without KVCache OOM, achieving up to 2.9x faster decoding at long context using speculative prefill and dynamic offloading.
@m_sirovatka: KV Cache re-use is the most important thing for agentic rollouts. We've integrated Mooncake Store into prime-rl with vL…
vLLM integrates Mooncake Store for distributed KV cache reuse, enabling cross-node prefix caching to efficiently serve agentic workloads with high token reuse.