SpaceDB — The Local-First Database That Replaces Firebase And DynamoDB

🪩 The Disco Party is MATA's distributed cloud — and SpaceDB is its database. Every replica lives on a device the user already owns.

SpaceDB is a local-first, CRDT-native, mesh-replicated database written in pure Rust. It stores encrypted application data across the devices of the users who own that data — not in a central data center — and converges automatically when replicas reconnect. It is designed to be the database layer of the distributed cloud, where "the cloud" is the set of machines the users already own rather than the set of racks a vendor keeps in one region.

For most application shapes today the default database is one of three products: Firebase Realtime Database or Firestore (mobile-first, opinionated, per-request pricing), DynamoDB (globally distributed inside AWS, priced by throughput), or Supabase (open-source Postgres with a hosted layer on top). All three assume the source of truth is a machine you rent from the vendor, that the network between the user and that machine will always be available, and that the price of running the whole thing scales with the number of active users. That model works — until any one of those three assumptions stops holding.

This article walks through why cloud-first databases broke user data in the first place, what SpaceDB does differently, and how it compares directly to Firebase, DynamoDB, and Supabase for the workloads each of those was built to handle. Full source on github.com/Remade-With-Rust/spacedb; more of the story behind the design lives in The Importance of Remade with Rust and in Tim Almond's field notes on Medium.

Why Cloud-First Databases Broke User Data

Every commercial database on the modern web was built for the same operating environment: a server-side application owned by a company, a mobile or web client used by many customers, and a network connection between the two that is assumed to work most of the time. The database is where the company keeps the customers' data on the company's own hardware. Every read and write flows across that network round-trip. Every outage on the network takes the whole product offline. Every dollar of database bill scales with the number of customers hitting it.

That set of assumptions has three problems that got worse the closer the cloud got to being ubiquitous. First, the network is not always there — mobile applications need to work on subway platforms and in basements, and a database that assumes always-on connectivity is a database that lies to the user about why the app is frozen. Second, the vendor becomes the trust boundary — the Electronic Frontier Foundation has documented for years how "we store this on our servers" quietly turns into "we've been served a subpoena for it" or "we've trained a model on it." Third, the pricing meter never stops running — the Federal Trade Commission's ongoing scrutiny of cloud market power has surfaced how per-request billing quietly turns hosting into a permanent tax on the product's growth.

SpaceDB was designed by starting from the opposite assumption: that the user's device is the source of truth, and any additional replicas — including any hosted infrastructure the developer chooses to run — are secondary. Read on for the specific mechanics that make that work.

What SpaceDB Does Differently

Three architectural choices flip SpaceDB relative to the cloud-first alternatives. Data lives locally by default. Multiple replicas converge without a central coordinator. Access control travels as a scoped capability instead of an ambient session. Each is a well-understood distributed-systems idea that individually would not amount to much; combined, they change the shape of the application on top.

Local-First: Data Lives Where The User Lives

SpaceDB's storage model treats every user's device as a first-class replica of that user's data. Writes commit to the local store immediately — before any network activity — so the application never blocks on network round-trips for correctness. Every replica is encrypted with keys the user controls, held on the user's own hardware, and never handed to the network operator in the clear. Losing a device does not lose the data if the user has another replica or has invited peers to hold ciphertext shards for them.

That single design choice takes several classes of failure off the board. Offline usage is not a "feature" that has to be added — it is the default state, and connectivity is what adds the sync layer on top. Latency is not a database concern — reads happen at local-disk speed. Data ownership is not a policy — the vendor cannot read what it does not hold the keys to.

CRDT Convergence: Conflicts Resolve Themselves

The hard part of any multi-replica database is what happens when two replicas write to the same field while offline from each other. Cloud-first databases resolve this by having one replica — the vendor's — designated as the source of truth; conflicts either error, get overwritten, or fall to whichever write reached the vendor first. That model does not work when there is no single source of truth to arbitrate.

SpaceDB is CRDT-native — every data type in the database is a conflict-free replicated data type, so two replicas that diverge will always converge on the same final state when they reconnect, without a coordinator and without dropping writes. The NIST Zero Trust Architecture guidance has been describing this posture in the abstract: assume every device is its own trust boundary, and design the software to survive any single one going offline. SpaceDB is that guidance made into a runtime.

Per-Field Consistency + Capability-Based Access

Not every field in a database has the same consistency needs. A counter that tracks reactions on a post is fine with eventual convergence; an account balance is not. SpaceDB exposes per-field consistency tiers — convergent, causal+, and strong — so a single schema can mix eventual and strong semantics where each fits, without dropping to raw locking primitives.

Access control follows the same "specific claim, not ambient session" pattern used elsewhere in MATA's stack. Callers do not authenticate against SpaceDB and then have blanket read access; they present a capability — a signed grant, scoped in time and scope — that says exactly what they can do. Revocation is instant. Delegation is composable. The whole design shows up in the identity story on the Remade with Rust page and threads into how the rest of the distributed cloud works.

SpaceDB Compared To Firebase, DynamoDB, And Supabase

The three databases most application teams pick between today have real strengths — SpaceDB is not a drop-in replacement for the specific workloads each was built for. What follows is a workload-by-workload comparison so the choice is honest, not marketing.

SpaceDB vs Firebase — The Realtime Database, Rebuilt Local

Firebase is optimized for a mobile app where every client sees updates from every other client in near-real time, and the developer wants to ship without ever writing a server. That shape works with SpaceDB, but the default is inverted. In Firebase every change makes a round-trip to Google's servers and then fans out; in SpaceDB every change commits locally and then gossips to peers when the mesh has connectivity. The user's app never freezes during a bad connection because it never depended on the connection to succeed.

Firebase has one runtime cost worth naming directly: per-request pricing that scales with active users. SpaceDB has no per-user meter. For applications that expect to grow — the shape of the whole Freedom Guide business tab is built on this — that difference is what turns hosting from a permanent tax into a fixed floor.

SpaceDB vs DynamoDB — Global Tables Without A Data Center

DynamoDB is optimized for high-throughput, single-region key-value workloads inside AWS, with an optional Global Tables layer for cross-region replication. Its convergence story is authoritative-source-inside-AWS: DynamoDB decides which write won when regions disagree, using last-writer-wins semantics that lose data in the general case.

SpaceDB's convergence story is different in a way that matters for user data. Every replica is coequal, CRDTs merge instead of overwriting, and there is no "authoritative region" that gets to arbitrate. For workloads where the data belongs to a person and they own multiple devices, that difference is the point. For workloads inside one company's boundary where a strict authoritative region model is what you want, DynamoDB is still the better fit — and SpaceDB happily coexists with a hosted DynamoDB layer if you need both.

SpaceDB vs Supabase — The Postgres Plus Layer, Without The Lock-In

Supabase deserves credit for building a genuinely open-source layer over Postgres and shipping a hosted version that is usable and honest. Its business model still assumes a hosted primary — the whole point of Supabase-the-service is that they run the Postgres. Migrating off of a Supabase deployment means self-hosting Postgres, which is possible but not trivial for most teams.

SpaceDB inverts that: there is no hosted primary to migrate off of, because there is no hosted primary in the first place. Every deployment ships with every user's own hardware as the replica set. For teams that want to keep Postgres for analytical queries and use SpaceDB for user-owned data, both can live in the same product without either owning the whole story. That composability is exactly what makes the distributed cloud thesis survivable in the short term while the ecosystem catches up. Homes that die are erasure coding. Files fetched by hash instead of a bucket URL are content-addressed storage. The full memory-safe stack that SpaceDB layers on lives on the Remade with Rust catalog.