@nuskey8: We've released lkv, a new embedded DB implementation in Rust. It's a lightweight KVS specialized for Point Lookup, achi…

X AI KOLs Timeline Tools

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.

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
Original Article
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

CI Crates.io Documentation GitHub License

A lightweight and fast embedded key-value store for Rust.

bench

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.

DBBulk 100k (ms)Write 1 (ms)Write 1k (ms)Read 100k (ms)Delete 1 (ms)Size (MiB)Size compacted (MiB)
std::HashMap11.48N/AN/A2.74N/AN/AN/A
lkv79.944.706.433.294.9429.179.44
redb169.364.987.1438.245.12128.5016.70
LMDB (heed)56.795.406.1950.125.0836.139.10
RocksDB65.235.406.8977.895.2210.0710.07
Fjall168.254.235.7171.054.9773.80N/A
sled686.084.4513.0555.135.7980.18N/A
SQLite (rusqlite)98.800.341.35545.170.4321.3910.51
jammdb132.795.239.8572.075.4564.50N/A

License

MIT

Similar Articles

Noxu DB, a Rust port of Berkeley DB Java Edition

Lobsters Hottest

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.