Learn/MemorySpaceDBdata management

What is SpaceDB and why could it be the future of data management?

SpaceDB is local-first data management: a CRDT-native database whose replicas live near the user, work offline, and converge without a data center.

Signed by Tim Almond·
Painted lakeside reading room at dusk where two cloth-bound ledgers face each other and soft mesh lights glow along the far shore
What is SpaceDB?

SpaceDB is a local-first, CRDT-native database. You open an encrypted replica on the device, write offline, and let peers converge without a data center as the system of record.

SpaceDB is a database for data management that does not begin with a connection string. The durable copy opens on the device in front of you. Replicas converge by CRDT rules. Access is a signed capability, not a password sitting in someone else's region. The crate is spacedb-sdk, dual-licensed MIT or Apache-2.0, and the source is the SpaceDB repository.

That is the short answer to a longer question: why this shape of data management could outlast the habit of renting a system of record. The builder field note is SpaceDB. The neighborhood argument is Your Database Should Not Need A Zip Code In California. The portfolio thesis is The Importance of Remade With Rust. The map is Vision.

What SpaceDB is

SpaceDB is data management with the default flipped. Rows live encrypted on machines near the people who own them. Writes work offline. When two replicas meet, they merge. The project describes itself as a local-first, CRDT-native, mesh-replicated database with no data center. MATA.NETWORK uses SpaceDB for its durable storage, and the repository publishes more than 1,596 active installs.

A database that opens on the device

You open a local replica for an identity, declare a schema, and write. There is no server in that first step. A profile can hold a text field, a register, and a counter. Each field also picks a consistency tier: convergent when automatic merge is enough, causal when the session should see its own writes, and strong when a value must be globally unique or cleanly refused. A strong claim that cannot reach a quorum comes back unavailable. It does not pretend two winners both committed.

Sync between two machines can be as small as exporting one collection's CRDT state and importing it on the other. Conflicts resolve by those rules, not by a tie-break in a distant region. A watcher tells the app when a local or merged write changed the collection, so the screen can refresh without polling a host. The types are documented on docs.rs. Applications take spacedb-sdk 0.5. A library should turn default features off so it does not force a process-wide allocator onto every downstream binary.

Consistency you can name per field

A lot of data management hides the consistency choice inside a slogan. SpaceDB puts it on the field. Convergent fields merge. Causal fields keep a session honest. Strong fields fail closed when the mesh cannot agree. Every operation reports the level it actually achieved, including a write that is durable here and still converging outward.

Under that surface the stack is layered, and each layer is a seam rather than a hidden service. Storage is an encrypted key-value boundary. The CRDT documents sit on yrs. Replica sync is anti-entropy over a transport you can fill in. Durability can shard with erasure coding and repair itself. Access is mID: signed, scoped, expiring, revocable capabilities, including a grant to an AI agent with its own budget. Query can run bounded compute next to the bytes. A vector index answers top-k on the node, and the corpus does not have to leave.

That last piece matters for retrieval. RAG Converter already keeps document conversion in the tab. SpaceDB is a shelf those chunks can live on when the index should stay near the reader. The product home for that habit is ragconverter.com.

Why SpaceDB could be the future of data management

The future of data management is not a faster dashboard on the same rented region. It is a system of record you can unplug and still explain. Central databases won because a single writer was easier to ship than a merge you can describe. That bargain rented truth to whoever held the region. SpaceDB keeps the merge rules and drops the requirement that one campus decide them.

The durable copy stays near the people

Local-first means the copy you edit is the real one. Offline is a normal morning, not a spinner labeled degraded. Delete means the bytes are on hardware you can point at. Several devices means replicas that merge, not thin clients of one brain.

dldeploy is the same instinct for sensors: cameras and presence that stay on the LAN. Data management belongs in that picture. A household mesh that phones a vendor for every row is a sensor story with the ending removed. dldeploy.com is that deployment. SpaceDB is the drawer those products can share when notes, device records, and access logs should converge without a campus in the middle.

Identity is the gate on that drawer. Your login should not belong to someone else is the human side. mID is the capability side: a grant can narrow, expire, and revoke, and the audit log is hash-chained. An agent gets a scope and a budget.

Search and compute stay with the bytes

Data management that ships every query to a region also ships the corpus. The SpaceDB vector path is the opposite: the question goes in, the top hits come out, the body stays. Deterministic compute can run beside the replica, with fuel and memory bounds, so a neighborhood node is not only a disk.

Placement is a separate decision from the library. The crates depend on nothing proprietary. The dependency arrow points from MATA into SpaceDB, not the reverse. When a product needs to reach people it does not already host, MATA.NETWORK in the wild is the field note for that mesh: repair, access, and placement around the seams SpaceDB defines. Integrate locally. Distribute when the product needs a network.

The allocator under a replica is part of whether other nodes can trust it. spacedb-sdk installs rusty_alloc by default so a memory bug aborts instead of silently corrupting a replica the mesh will believe. A library author opts out. An application decides.

What to decide before you bet a product on SpaceDB

SpaceDB will not repair a careless schema. It will make the consistency choice visible, which is uncomfortable if the product was hiding a single-writer assumption. Bet on it when the durable copy should survive a partition, and when you can name which fields may merge and which fields must refuse.

Embed the library, then distribute

Start on one machine. Open a replica, define the collections, grant a capability, write, and read back the outcome. Sync a second replica by exchanging CRDT state before you invent a server. Only then decide whether mesh placement is in scope. The library is yours either way. Deputy is how you keep the crates under that choice auditable before the binary lands on hardware you do not babysit. cargo update is not a security model is the longer argument: a green badge is not a supply-chain warranty.

Where SpaceDB sits beside the rest of the house

SpaceDB is Memory. It sits next to the allocator, under Identity, beside Mind when a transcript should never have been uploaded, and beside Media when a file should open without a host in the middle. Filter Learn by Memory for the sibling field notes, and read the California essay again when you want the polemic rather than the crate.

If this bet is right, the future of data management looks like two desks with the same ledger and a lake between the houses. Tuesday morning does not require a status page. The source of that bet remains the SpaceDB repository.

FAQ

Quick answers for builders evaluating this technology.

Why could SpaceDB be the future of data management?

Because the durable copy stays on hardware near the user, merges by CRDT rules, and can refuse a strong write when the mesh has no quorum instead of inventing a second winner.

Does SpaceDB need a server to sync two devices?

No. One replica can export a collection's CRDT state and another can import it. Conflicts resolve by the CRDT rules. A server is optional, not the first step.

How does SpaceDB grant access to a person or an agent?

With an mID capability that is signed, scoped, expiring, and revocable. An agent can receive its own scope and spend budget instead of a shared root password.

Which consistency choices can a field make?

Convergent fields merge automatically. Causal fields keep a session's own writes visible. Strong fields commit only with agreement, or they come back unavailable.

Where should a team start with SpaceDB?

Add spacedb-sdk, open one local replica, and read the field note. Distribute on MATA.NETWORK only after the local copy already makes sense without a connection string.