Open-Source Databases · spacejam

sled

Sled is an embedded key-value database written in Rust designed for high-concurrency, long-running services. It combines log-structured storage with B+ tree semantics, offering atomic operations, transactions, and automatic crash recovery without requiring a separate server process.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/spacejam/sled

GitHub stars

427

Forks

Rust

Primary language

Apache-2.0

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	spacejam/sled
Owner	spacejam
Primary language	Rust
License	Apache-2.0 — OSI-approved
Stars	9k
Forks	427
Open issues	171
Latest release	v0.34.7 (2021-09-12)
Last updated	2026-04-04
Source	https://github.com/spacejam/sled

What sled is

Lock-free concurrent B+ tree with log-structured merge semantics, providing ACID transactions, zero-copy reads, compare-and-swap operations, and configurable fsync durability (default 500ms). Implements prefix encoding, suffix truncation, and scatter-gather page reconstruction for flash-optimized storage.

Quickstart

Get the sled source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/spacejam/sled.git2cd sled3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Embedded state stores for stateful services

Long-running Rust services (microservices, game servers, message brokers) needing local persistent state without operational database overhead. Single-process, in-memory-cache-friendly architecture.

High-concurrency read-heavy workloads

Applications with heavy read traffic and moderate writes where lock-free performance is critical. Benchmarked for billions of operations per minute on multi-core systems with 95% read/5% write ratios.

Building blocks for higher-level databases

Foundation for domain-specific databases, time-series stores, or search indexes where the raw embedded KV engine is layered into a more complex system.

Implementation considerations

API mirrors std::BTreeMap<[u8], [u8]>; all keys and values are byte slices. Use IVec (inlinable Arc slice) for in-memory representation; no built-in serialization—users must handle serde or bincode themselves.
Transactions are optimistic and non-blocking; do not perform external IO or side effects inside transaction closures unless idempotent, or accept retry semantics.
Numerical keys must be stored big-endian (e.g. u64::to_be_bytes()) to align lexicographic byte ordering with numeric ordering; little-endian will silently break range queries above 256 items.
Default fsync interval is 500ms; configure flush_every_ms or call flush()/flush_async() manually if stronger durability SLAs are required.
Single open instance per process. Use lazy_static or once_cell for global safe access; operations are thread-safe but multiple Db::open() calls to the same path are not supported.

When to avoid it — and what to weigh

Absolute reliability is non-negotiable — README explicitly states 'if reliability is your primary constraint, use SQLite.' Sled is still in beta; durability is automatic but 500ms default fsync interval may not meet strict ACID guarantees for all use cases.
Storage cost or space efficiency is critical — README notes 'if storage price performance is your primary constraint, use RocksDB. sled uses too much space sometimes.' Space overheads are not fully quantified.
Multi-process concurrent access required — Sled does not support multiple open instances to the same database. Architected for single long-running process; multi-process workloads must implement external serialization.
You need predictable, sub-millisecond latency — Automatic background fsyncs and log-structured compaction can introduce unpredictable latency spikes. No real-time guarantees documented.

License & commercial use

Apache License 2.0 (Apache-2.0). Permissive OSI-approved open-source license allowing commercial use, modification, and distribution with liability disclaimer and license notice requirements.

Apache-2.0 is a permissive license suitable for commercial use. However, the README warns that sled is in beta and the on-disk format will change before 1.0.0, requiring manual migrations. Evaluate stability and support maturity for production workloads; no SLA or commercial support vendor mentioned.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Adequate
License clarity	Clear
Deployment complexity	Low
DEV.co fit	Good
Assessment confidence	High

Security considerations

No explicit security audit or formal verification mentioned in provided data. Lock-free implementation reduces deadlock risk but increases complexity surface. No mention of encryption at rest, TLS transport, or access control. Fuzzing and formal-methods mentioned as topics but no detailed results provided. Evaluate threat model and consider sled's beta status when assessing security posture for sensitive data.

Alternatives to consider

SQLite

Mature, single-file, ACID-compliant embedded database with broader language support. Preferred if reliability is the primary constraint (per sled's own README guidance).

RocksDB

Production-proven LSM tree KV store with better space efficiency and optional multi-process support via shared libraries. Preferred if storage cost/performance ratio is critical.

LMDB

Lightweight, multi-process-safe memory-mapped B+ tree with minimal write overhead. Preferred for multi-process read-heavy workloads; lower concurrency than sled.

Software development agency

Build on sled with DEV.co software developers

Sled is powerful for stateful Rust services but carries beta-stage risks and design constraints (single-process, durability tuning, format migration). Let's help you assess fit against your reliability, performance, and operational requirements.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

rust-rocksdb PoloDB fjall

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Databases Custom Software Development API Development DevOps Talk to DEV.co

sled FAQ

Is sled production-ready?

Sled is beta. README explicitly recommends SQLite if reliability is your primary constraint. On-disk format will change before 1.0.0, requiring manual migrations. Suitable for stateful services and embedded use cases where stability risk is acceptable.

Does sled support multiple processes accessing the same database?

No. Sled does not support multiple open instances. Keep a single Db::open() call per process and use lazy_static or once_cell for global access. Multi-process workloads must implement external serialization.

How does durability work?

Sled automatically fsyncs to disk every 500ms by default (configurable via flush_every_ms). Call flush() or flush_async() explicitly for stronger guarantees. Transactions are optimistic and fully ACID within a single process.

What's the performance profile?

Benchmarked for over a billion operations per minute on 16 cores at 95% read / 5% write ratios on small datasets. Lock-free design and log-structured storage optimize for modern hardware but introduce variable latency from background compaction. Measure your own workloads.

Software development & web development with DEV.co

From first prototype to production, DEV.co delivers software development services around tools like sled. Our software development agency staffs experienced software developers and web developers for custom software development, web development, integrations, and ongoing support across open-source databases and beyond.

Evaluating Sled for your embedded database layer?

Talk to DEV.co Schedule a Consultation