◉ COOLJAPAN
← All posts
June 23, 2026 • 7 min read

OxiStore 0.2.0 — The Pure Rust Low-Level Storage Layer (no RocksDB, no LevelDB, no -sys)

Meet OxiStore: the COOLJAPAN Pure Rust low-level storage layer — embedded key-value (B-tree + LSM), columnar in-memory & on-disk, and a blob abstraction (local fs + S3/Azure/GCS). Replaces librocksdb-sys, lmdb-sys, and leveldb-sys with zero FFI. Part of the NoFFI sovereign Rust stack.

release oxistore pure-rust cooljapan noffi storage key-value columnar blob database

Persistence is the layer everybody depends on — so it should be the layer nobody has to fear.

Today we’re releasing OxiStore 0.2.0 — the COOLJAPAN Pure Rust low-level storage layer: embedded key-value, columnar in-memory & on-disk, and a blob storage abstraction spanning local filesystem and the major clouds.

No RocksDB. No LevelDB. No LMDB. No FFI. No -sys crates. Just a clean, memory-safe storage foundation that compiles in a fresh rust:slim container with no apt-get install and no C toolchain in sight.

Why OxiStore

The Rust ecosystem has a quiet dependency problem hiding at the bottom of the stack. The moment a project needs durable storage “without SQL overhead,” it reaches for rocksdb (C++), lmdb-rkv-sys (C), or leveldb-sys (C++). Suddenly your pure-Rust crate carries a native build dependency, a system library, and a cargo build that fails on any machine missing librocksdb-dev.

Across COOLJAPAN we kept hitting this same wall. oxirs needs a triplestore. oxionnx needs a model cache. oximedia needs an asset DB. oxirag needs a vector-store backend. oxify needs session storage. Each one wanted a fast embedded KV engine — and each one was being pulled toward a C/C++ engine and an FFI boundary.

OxiStore exists so none of them ever have to. It is deliberately the layer below SQL: OxiSQL sits on top when you want queries; OxiStore is the raw key-value, columnar, and blob substrate beneath it. The non-negotiable design goal was simple — cargo build --workspace --no-default-features should produce a working KV store with no C toolchain. cargo tree --workspace --no-default-features shows zero *-sys crates. That’s the whole point.

What we built

OxiStore is a 13-crate workspace, each piece doing one job well and composing through a small set of core traits.

1. The core abstraction (oxistore-core) At the center are the KvStore, KvTxn, and KvSnapshot traits, plus StoreError, TTL support, compare-and-swap (CAS), batch operations, and a TypedKvStore for working with structured values instead of raw bytes. Every backend implements this same surface, so swapping engines is a configuration change, not a rewrite.

2. Three pluggable KV engines OxiStore doesn’t pick one storage architecture and force it on you — it gives you the right tool for the workload:

B-tree when you read more than you write, LSM-tree when you write more than you read — same trait, your choice.

3. Columnar storage (oxistore-columnar) Parquet/Arrow columnar storage with predicate pushdown, a streaming writer, and OxiARC codecs — in-memory analytics format and on-disk persistence, without dragging in a C-based Parquet stack.

4. Cache primitives (oxistore-cache) A real eviction toolkit: LRU, ARC, LFU, and W-TinyLFU policies, per-entry TTL, and write-through / write-back adapters so a cache can sit transparently in front of any KvStore.

5. A blob storage abstraction (oxistore-blob + cloud backends) A BlobStore async trait with content-addressable, streaming semantics. Local filesystem and in-memory backends ship in the core crate; three cloud backends fill out the rest, every one of them Pure Rust:

6. Encryption & compression (oxistore-encrypt, oxistore-compress) Cell-level AEAD encryption-at-rest using XChaCha20-Poly1305 via OxiCrypto, exposed as an EncryptedKv<T, K, A> decorator that wraps any backend. Compression is handled by an OxiARC DEFLATE codec bridge for Parquet — never flate2, zstd, brotli, or miniz_oxide.

7. The facade (oxistore) Tying it together is a single front-door crate offering open, open_with, and open_in_memory, each returning a Box<dyn KvStore>. You don’t have to know which engine you’re using to start using it.

Getting Started

Add the facade crate:

cargo add oxistore

Or in Cargo.toml:

[dependencies]
oxistore = "0.2.0"

Basic key-value operations — open a store, put, get:

use oxistore::{open, KvStore};

let store = open("/tmp/my-store").expect("open failed");
store.put(b"hello", b"world").expect("put failed");
let val = store.get(b"hello").expect("get failed");
assert_eq!(val.as_deref(), Some(b"world".as_ref()));

By default you get the redb B-tree backend — single-file, ACID, no native dependencies.

Highlights

Tips

Part of the COOLJAPAN ecosystem

OxiStore is part of NoFFI — the COOLJAPAN initiative to replace every C/C++/Fortran/-sys FFI dependency in the Rust world with a clean, memory-safe, 100% Pure Rust implementation. Default features are 100% Pure Rust: a single static binary, no system libraries, no build-time C toolchain, WASM-friendly. OxiStore’s specific job is retiring librocksdb-sys, lmdb-sys, and leveldb-sys.

It sits among siblings it both leans on and serves. It depends on oxicrypto (encryption-at-rest), oxiarc (compression + Parquet codec), oxitls (cloud blob TLS — rustls + rustcrypto, never ring), and oxihttp (cloud HTTP client). In turn it underpins oxisql (SQL atop KV + columnar), oxirs (RDF triplestore), oxionnx (model cache), oxirag (vector embeddings persistence), oximedia (asset blob storage), and oxify (session and token KV).

Repository: https://github.com/cool-japan/oxistore

Star the repo ⭐ if you want a Rust ecosystem where the storage layer at the very bottom is finally sovereign.

Pure Rust storage — sovereign, safe, and FFI-free.

— KitaSan at COOLJAPAN OÜ June 23, 2026

↑ Back to all posts