The local-first, decentralized
database for the modern web
GuardianDB is a high-performance, peer-to-peer database where every node keeps a full local replica. Reads and writes are instant and offline-friendly. Changes converge across peers automatically over Iroh. No servers. No central point of failure.
A database that lives on every device
GuardianDB began as a Rust port of OrbitDB, but it's no longer "OrbitDB in Rust". The legacy IPFS / CID / libp2p stack is gone, replaced by Iroh's QUIC transport, BLAKE3 hashing, and Willow range-based set reconciliation.
Local-first & offline
Every node holds a full replica. Reads and writes never touch a server, so your app keeps working with no connection at all.
True peer-to-peer
Direct, encrypted connections via Iroh's Magicsock. NAT traversal, hole punching and Wi-Fi ⇄ 5G roaming with no global DHT.
CRDT conflict-free sync
Last-Write-Wins CRDTs and a causal DAG mean concurrent edits converge automatically. No merge conflicts, no coordinator.
Blazing fast
Willow transfers only the diff between peers, millions of records in milliseconds. BLAKE3 + QUIC keep hashing and transport hot.
Secure by design
Each peer is an Ed25519 identity (its 32-byte address). Every connection is end-to-end encrypted out of the box.
Multiple store types
Event Log, Key-Value, and Document stores. Plus an optional TypeORM/Mongoose-style ODM with schemas, indexes and CRUD.
The technology stack
Modern, no-compromise building blocks chosen for performance, safety and decentralization.
What changed under the hood
| Concept | Legacy (IPFS / OrbitDB) | GuardianDB (Iroh) |
|---|---|---|
| Identity | PeerID (Multihash) | EndpointID (Ed25519, 32 bytes) |
| Content ID | CID (SHA-256 + codecs) | Hash (BLAKE3) |
| Network | libp2p swarm (TCP / WS) | Iroh Endpoint (QUIC) |
| Discovery | Kademlia DHT (global) | Pkarr / DNS + mDNS, direct |
| Data format | IPLD DAG (JSON) | Binary (Postcard) |
| Sync | Bitswap (block-by-block) | Willow (range-based) |
use guardian_db::guardian::GuardianDB;
use guardian_db::p2p::network::client::IrohClient;
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// Start a local Iroh node and open a persistent database.
let client = IrohClient::development().await?;
let db = GuardianDB::new(client, None).await?;
// Open a key-value store — writes replicate to peers automatically.
let kv = db.key_value("settings", None).await?;
kv.put("theme", b"dark".to_vec()).await?;
if let Some(v) = kv.get("theme").await? {
println!("theme = {}", String::from_utf8_lossy(&v));
}
Ok(())
}Everything you want to know
What is GuardianDB for?
GuardianDB is for building applications that need peer-to-peer synchronization, offline-first operation, and high performance without a central server. Every node keeps a full local replica, so reads and writes happen locally with no network round-trip, and changes converge across peers automatically over Iroh.
It's a great fit when you want your data to be owned by the people using it, to keep working with zero connectivity, and to sync directly between devices and users when a connection is available.
What are the use cases of GuardianDB?
Anywhere central servers are a cost, a bottleneck, or a single point of failure:
- Local-first & offline-first apps: note-taking, editors and productivity tools that must work with no connection.
- Real-time collaboration: shared documents, whiteboards and multiplayer state via CRDT merging.
- Decentralized & Web3 apps: user-owned data with no backend to operate.
- Edge & IoT: devices that sync directly with each other on a LAN or across the internet.
- Messaging & presence: direct encrypted channels and real-time gossip signaling.
- Audit logs & event sourcing: the append-only Event Log store keeps a tamper-evident, causally-ordered history.
How do I scale GuardianDB?
Because there's no central server, you don't scale a bottleneck, you add peers and tune how they connect and sync.
- Reads & writes are local, so read throughput scales linearly with the number of nodes; writes apply locally and propagate asynchronously.
- Sync cost is proportional to the diff, not the dataset.Willow range-based reconciliation only exchanges what two peers are missing, so steady-state sync stays cheap as data grows.
- Tune connectivity with
enable_discovery_mdns(LAN),enable_discovery_n0(global Pkarr/DNS) andknown_peersfor bootstrapping. - Turn the knobs that matter in
ClientConfig:max_peers_per_session(100 → 1000), blob cache (100 MB → 1 GB), gossip buffers and timeouts. Start fromClientConfig::production(). - For internet-spanning deployments, run always-on "super peers" as stable rendezvous/sync points, and partition independent workloads by database name and gossip topic.
Is GuardianDB production-ready?
GuardianDB is in active development and there will be breaking changes. There are no stability guarantees at this stage, though resulting issues are usually easy to fix. It's dual-licensed under MIT and Apache 2.0, so it's free to use, study and build on.
What languages can I use it from?
The core is a native Rust crate (guardian-db on crates.io). There's also an optional ODM layer with derive macros for schema modeling, and a TypeScript/JavaScript SDK that exposes a MongoDB-style collection API (insertOne, find, update with $set/$inc, and more).
Become a contributor
If you're into distributed systems, Iroh, decentralized databases, or just want to get your hands dirty with a different kind of open-source project, join us! Whether it's code, docs, ideas or bug reports, there's a place for you here.