Bridging OrbitDB with Storacha: Decentralized Database Backups

How do we back up and restore decentralized databases in a way that is verifiable, reliable, and developer-friendly?

Storacha

— 5 min read
Bridging OrbitDB with Storacha: Decentralized Database Backups

This guest post comes from Nico Krause, a team member exploring innovative ways to bring secure, verifiable workflows to life using Storacha.

In this write-up, they share how building an OrbitDB Storacha bridge is used to provide effortless backups and one-command restores. Read the original post here.

Introduction

In today’s decentralized ecosystem, data ownership and resilience are more important than ever. Distributed applications rely on decentralized databases like OrbitDB for peer-to-peer state management, but there’s always one big question:

How do we back up and restore decentralized databases in a way that is verifiable, reliable, and developer-friendly?

Orbitdb Storacha Bridge library seamlessly connects OrbitDB with Storacha a decentralized hot storage layer built on Filecoin to provide effortless backups and one-command restores. With just a few lines of code, developers can preserve their database across a decentralized storage network, ensuring permanence, verifiability, and recoverability.

What is OrbitDB?

OrbitDB is a serverless, distributed, peer-to-peer database built on IPFS and libp2p. Unlike traditional databases, OrbitDB doesn’t require centralized servers. Instead, it uses Merkle-CRDTs to ensure conflict-free replication across peers.

Key features of OrbitDB:

  • Decentralized: No single point of failure.
  • Multiple data models: Key-value store, event log, documents, counters, etc.
  • Content-addressed: Every database entry is represented by a CID (Content Identifier).
  • Use cases: Ideal for dApps, blockchain metadata storage, local-first apps, and distributed systems.

OrbitDB ensures that applications can run independently of centralized infrastructure but without backups, even decentralized systems risk losing continuity.

OrbitDB at a Decade: A Turning Point

With OrbitDB turning 10 and version 3.0 unlocking stability, and with Helia/libp2p enabling browser-native nodes, we’re standing at the edge of a software architectural shift

What is Storacha?

Storacha is a decentralized hot storage network designed to complement Filecoin by offering CDN-like performance with IPFS compatibility. Think of it as the high-speed “edge layer” for decentralized data.

Storacha provides:

  • Scalable, low-latency storage for real-world apps.
  • Filecoin-backed permanence with redundancy.
  • UCAN-based permissions (User-Controlled Authorization Networks) for secure access.
  • Developer-first SDKs for JavaScript, Go, and CLI.
  • High availability (99.9%) with data integrity validation.

For developers, Storacha feels like using a modern cloud storage service but without centralization risks.

The goal of the orbitdb-storacha-bridge is to show how decentralized storage can power real developer workflows. OrbitDB by itself is great for peer-to-peer apps, but:

  • Backups can be tricky to manage.
  • Developers want permanence and redundancy.
  • Restores should be fast and identity-preserving.

Storacha provides the perfect fit:

  • Speed: Hot storage means fast backup and retrieval.
  • Redundancy: Filecoin ensures data permanence.
  • Verifiability: CIDs + Merkle proofs validate integrity.
  • Ease of use: Simple APIs make integration seamless.

In short, Storacha transforms OrbitDB from a purely peer-to-peer database into a resilient, production ready storage solution.

Architecture & Workflow

Let’s break down how the bridge works.

OrbitDB Storacha Bridge

Backup Flow

  1. Extract Database Blocks
    > OrbitDB consists of multiple blocks: log entries, manifest, identity, and access control.
    > The bridge decomposes the database into these components.
  2. Upload to Storacha
    Each block is uploaded to Storacha, stored as content-addressed chunks (CIDs).
  3. Discovery & Indexing
    Files are registered inside a Storacha “space” for easy listing and future restoration.

Restore Flow

  1. CID Conversion
    1. Storacha provides Filecoin/IPFS CIDs (bafkre...).
    2. OrbitDB expects its own CID format (zdpu...).
    3. The bridge automatically translates between the two.
  2. Reassembly
    1. The database is rehydrated from the recovered blocks.
    2. Identity and access control metadata are preserved.

Roadmap

  1. Current Status
    The OrbitDB Storacha bridge library integrates into a local-first peer-to-peer todo app, enabling backup and restore when peers or relays become unreachable.
  2. Next Step: CustomStores
    Implement Storacha as a custom storage backend within OrbitDB.
    This means backups become implicit: every update is pushed in parallel to Storacha, enabling fresh installs of OrbitDB to sync immediately even without peer availability.
  3. Authentication Upgrade: UCAN Delegation
    Currently, the library uses Storacha Key + Proof credentials. Future contributions aim to introduce delegated UCAN-based authentication, simplifying onboarding and access flow.
  4. Hybrid SSR + PWA Mode
    Build hybrid apps using SSR frameworks (Next.js, SvelteKit, etc.) that fallback to full client-side P2P operation if servers go down. Such resilience enables apps to keep operating and replicating critical data even in infrastructural failure scenarios.

Quickstart & Code Examples

Getting started is incredibly simple.

Install

npm install orbitdb-storacha-bridge

Backup a Database

import { backupDatabase } from "orbitdb-storacha-bridge"; 
 
const backup = await backupDatabase(orbitdb, dbAddress, { 
  storachaKey: process.env.STORACHA_KEY, 
  storachaProof: process.env.STORACHA_PROOF, 
}); 
 
console.log(`✅ Backed up ${backup.blocksUploaded} blocks`);

Restore a Database

import { restoreDatabaseFromSpace } from "orbitdb-storacha-bridge"; 
 
const restore = await restoreDatabaseFromSpace(targetOrbitdb, { 
  storachaKey: process.env.STORACHA_KEY, 
  storachaProof: process.env.STORACHA_PROOF, 
}); 
 
console.log(`✅ Restored ${restore.entriesRecovered} entries`);

That’s it backup and restore in three lines of code.

Resources

  1. Source Code: NiKrause/orbitdb-storacha-bridge
  2. Relevant Docs:
    > Storacha : docs.storacha.network
    > OrbitDB: api.orbitdb.org
  3. For Demo & Tests refer Readme.md.

Conclusion

The orbitdb-storacha-bridge project highlights the future of decentralized applications: databases that are resilient, verifiable, and permanently backed up all without relying on centralized servers.

With just a few lines of code, developers can:

  • Back up OrbitDB databases into Storacha.
  • Restore them with integrity and identity preserved.
  • Confidently build apps that won’t lose critical data.

If you’re building decentralized applications, this bridge is a must-try.

Glossary

  1. Peer-to-Peer Database (P2P DB)
    A database that does not rely on a central server. Instead, every participant (peer) maintains a copy of the database and synchronizes directly with others. In OrbitDB, peers exchange changes over IPFS/libp2p, meaning the app can continue working even if some peers or servers go offline.
  2. OrbitDB
    A distributed, peer-to-peer database built on top of IPFS. It supports multiple store types (key-value, log, documents, counters) and works in both Node.js and modern browsers.
  3. IPFS (InterPlanetary File System)
    A decentralized protocol for storing and sharing files using content addressing (files are identified by their hash, called a CID). OrbitDB uses IPFS for storage and transport.
  4. CID (Content Identifier)
    A unique, cryptographic hash that identifies content in IPFS. Instead of referring to “where” a file is stored (like a URL), a CID identifies “what” the file is.
  5. Libp2p
    A modular peer-to-peer networking stack used by IPFS and OrbitDB. It enables peer discovery, transport (WebRTC, TCP, WebSockets), encryption, and messaging.
  6. Helia
    The modern successor to js-libp2p, designed for IPFS in browsers. It enables lightweight peer-to-peer nodes to run client-side, letting users spin up IPFS + OrbitDB instances directly in their browser.
  7. Manifest
    Metadata that defines how an OrbitDB database is created and identified. It includes the database type, access controller, and other configuration details.
  8. Identity
    OrbitDB uses cryptographic identities (public/private key pairs) to sign and verify database entries. This ensures only authorized peers can write to a database.
  9. Access Controller
    The component in OrbitDB that defines who can write (or replicate) to the database. Common controllers include IPFSAccessController or custom implementations.
  10. Blocks
    The smallest unit of content in IPFS. Files and database entries are broken into blocks, each identified by its own CID. Storacha backs up OrbitDB by storing these blocks.
  11. Storacha
    A decentralized, Filecoin-backed storage layer designed to be UCAN-native and backend-less. It provides primitives like spaces, proofs, and delegations for secure and composable storage.
  12. UCAN (User Controlled Authorization Networks)
    A cryptographic, delegation-based authorization system. Instead of centralized API keys, UCANs allow users to delegate permissions securely and verifiably. Planned for future integration in OrbitDB–Storacha bridge.
  13. CustomStores (OrbitDB)
    OrbitDB supports defining custom storage backends. In the future, Storacha could be plugged in directly as a CustomStore so backups happen implicitly with every write.
  14. Hybrid Applications (SSR + P2P)
    Apps that combine server-side rendering (SSR) frameworks (like Next.js or SvelteKit) with local-first peer-to-peer replication. Even if the SSR server fails, the client-side app (as a PWA) continues to run and sync via OrbitDB + IPFS + Storacha.

Read more