OSS Tanbou

use S3-compatible object storage as the durable layer for an embedded cloud-native LSM engine

About these scores

OSS scale score is an unbounded metric that log-compresses and weights Stars, Watchers, Forks, and Contributors. Discovery score is the current OSS scale score minus the score at discovery. Update pace is commits in the last 30 days, growth momentum is the OSS scale score difference within the recent observation window, and OSS health is a 0–100 rating based on available recency, Community Health, and release data.

Stars
3,455
Primary language
Rust
License
Apache-2.0
Repository last updated
Sep 29, 2026
On this page

Overview

SlateDB is an embedded log-structured merge-tree storage engine that writes SSTs and metadata to object storage such as S3, GCS, Azure Blob Storage, and MinIO instead of relying on local disk. Rust is the primary implementation, with official bindings for several other languages.

Features and best fit

Based on official documentation; not hands-on tested · Content checked:

Key features

Use object storage as the durable storage layer

ObjectStore implementations, including S3-compatible systems, provide capacity, durability, and replication characteristics underneath the embedded engine.

Sources: [2]

Reduce object-store cost with MemTables, SSTs, and caches

Writes are batched instead of issuing a remote operation for every put, then MemTables are flushed as SSTs. Reads use in-memory block caches, compression, Bloom filters, and local SST disk caches to reduce GET latency and API cost.

Sources: [2]

Support transactions, clones, CDC, and database split or merge

Beyond get, put, delete, and range scans, SlateDB implements transactions, merge operators, clones, change data capture, and database split or merge workflows.

Sources: [2][3]

Best fit

Fits systems embedding a KV layer whose durable state belongs in cloud object storage

It is relevant for database, streaming, and stateful-service architectures that want to avoid keeping the full durable dataset on local disks.

Sources: [2]

Before adoption

Design around object-store latency and API cost

The README explicitly notes that object storage has higher latency and API cost than local disk. Evaluate read and write patterns, flush intervals, and cache sizing together with cloud cost.

Sources: [2]

Compile-time API compatibility is not currently guaranteed

The release policy guarantees storage-format forward and backward compatibility between adjacent versions but reserves the right to break compile-time API compatibility. Review library changes before upgrades.

Sources: [2]

Use a real object store and explicit durability boundaries in production

The minimal README example uses an in-memory object store. Production code should configure the intended cloud ObjectStore and use await_durable() or flush() where a durable write boundary is required.

Sources: [2]

Official sources

  1. [1]slatedb/slatedb repository(2026-10-01)
  2. [2]SlateDB README(2026-10-01)
  3. [3]SlateDB v0.17.0 release(2026-10-01)
  4. [4]SlateDB Apache-2.0 license(2026-10-01)
Supplemental curator note

Unlike local-disk engines such as RocksDB, SlateDB uses S3, GCS, ABS, MinIO, and other object stores as its durable layer. Its batching and caching compensate for object-store latency and API cost, so evaluate it for object-storage-native workloads rather than as a drop-in local database.

Try it in 3 steps

  1. 1

    Create a Rust project

    Create a minimal Rust application for evaluating SlateDB.

    cargo new slatedb-demo && cd slatedb-demo
  2. 2

    Add SlateDB 0.17.0 and Tokio

    Pin the latest stable SlateDB v0.17.0 release and add the async runtime.

    cargo add slatedb@0.17.0 && cargo add tokio --features full
  3. 3

    Run a put/get with the in-memory object store

    Run the same minimal in-memory flow shown in the README. Replace InMemory with S3, GCS, MinIO, or another ObjectStore for production evaluation.

    cat > src/main.rs <<'RS' use slatedb::{Db, Error}; use slatedb::object_store::{ObjectStore, memory::InMemory}; use std::sync::Arc; #[tokio::main] async fn main() -> Result<(), Error> { let store: Arc<dyn ObjectStore> = Arc::new(InMemory::new()); let db = Db::open("/demo", store).await?; db.put(b"hello", b"slatedb").await?; println!("{:?}", db.get(b"hello").await?); db.close().await?; Ok(()) } RS cargo run
Check the official README

Growth

Growth trends · Last 30 days

3,455 Stars

Trend data is still being collected.

Built with

Categories and tags

GitHub data

GitHub dataView detailed GitHub data

GitHub Topics

  • database
  • embedded-database
  • lsm-tree
  • object-storage
  • rocksdb
  • rust
  • storage-engine
Stars
3,455
Forks
306
Watchers
28
Open issues
202
Owner type
Organization
Primary language
Rust
License
Apache-2.0
Repository last updated
Sep 29, 2026
Write a related article

Share a guide or use case for this OSS in Markdown. Articles are published after administrator approval.

Report incorrect information

Tell us if any listing information is incorrect or outdated.

After reading this page, do you know what to do next?