Learn/MemorySpaceDBperformance

SpaceDB 0.7.0: Same Results, Far Fewer Instructions

SpaceDB 0.7.0 keeps the same measured results as 0.6.0 and spends 58.3 percent fewer callgrind instructions across eight release-build drivers.

Signed by Tim Almond·
Painted study at dusk where two open ledgers share the same warm light across a quiet room
What did the SpaceDB 0.7.0 performance release change?

SpaceDB 0.7.0 keeps the same driver results as 0.6.0 and cuts instruction counts. Across eight measured drivers the total fell from 5,702 million instructions to 2,378 million, a 58.3 percent drop. The count is callgrind instructions, not a wall-clock benchmark.

SpaceDB 0.7.0 is a performance release of the local-first database, and the number that matters is not a slogan. Across eight deterministic drivers, instruction counts fell from 5,702 million to 2,378 million. That is 58.3 percent less work for the same printed results. The crate on crates.io is spacedb-sdk 0.7.0, published 10 October 2026.

This note is the measurement. The model of the database, local replica, CRDT merge, capability access, is already in What is SpaceDB. The builder brief is SpaceDB. The argument for keeping the durable copy near the user is Your Database Should Not Need A Zip Code In California. The program thesis is The Importance of Remade With Rust.

What the 0.7.0 numbers actually say

SpaceDB 0.7.0 was kept on one rule. A change landed only if its instruction count went down and the driver's printed values stayed identical. Refuted changes were reverted, and the number that refuted them was kept on record. The count is callgrind Ir: retired instructions, not milliseconds on a laptop. Same results, less work. That is the whole claim.

Same results, fewer instructions

The eight drivers, 0.6.0 to 0.7.0, on a release build:

  • ir_sdk, authorize plus write plus read, 330 operations: 1,136.6 million to 12.2 million, down 98.9 percent.
  • ir_access, authorize, delegation chains, and the audit log: 1,362.5 million to 95.6 million, down 93.0 percent.
  • ir_query, a WASM map-reduce plus a host call: 280.9 million to 33.4 million, down 88.1 percent.
  • ir_vector, 1,500 vectors of 64 dimensions, three metrics, top 10: 204.2 million to 33.1 million, down 83.8 percent.
  • ir_crdt, every CRDT type plus sealed persistence: 199.8 million to 151.1 million, down 24.4 percent.
  • ir_sim, 40-replica gossip, causal delivery, quorum, and churn: 2,060.5 million to 1,663.3 million, down 19.3 percent.
  • ir_durability, erasure encode and reconstruct: 40.6 million to 33.1 million, down 18.6 percent.
  • ir_store, sealed puts, gets, and ranges: 416.9 million to 356.1 million, down 14.6 percent.

The operator console driver, ir_console, was added in this release and moved from 91.0 million to 82.9 million, down 8.8 percent, before the build change described below. It is not inside the eight-driver total.

The SDK path dropped the most

The headline is the SDK driver. Authorize, write, and read, 330 times, used to cost about 1.14 billion instructions. In SpaceDB 0.7.0 that path is 12.2 million. A product that opens a session and then writes a profile is no longer paying a signature tax on every call. Access control is the next cut, from 1.36 billion instructions to 95.6 million, because delegation chains and the audit log stopped repeating work the process had already done.

Those two drivers are why the release feels large even though store, durability, and the simulator moved by tens of percent rather than by an order of magnitude. The hot path an application actually sits on was the expensive one. SpaceDB 0.7.0 spent the budget there.

Where the instructions went

The README groups the cuts from largest to smallest. None of them change the CRDT rules, the consistency tiers, or the promise that a strong write comes back unavailable when the mesh has no quorum. The merge is the same. The bill for doing it is smaller.

Work done once

Compiled WASM modules are cached by workload hash, so a query does not recompile a module it already trusts. An SDK session verifies its capability signature once and re-checks only if the issuer's published key changes. Signatures already verified are remembered for the process, bounded, successes only, keyed by a BLAKE3 of the key, the message, and the signature. Erasure coders are built once per geometry instead of once per shard. A range scan builds one cipher and reuses it.

That is also why two behaviors are intentionally different. CrdtStore::contains is now a presence check: it does not need the vault unlocked, and it does not decrypt the document to answer "is this here." A log walk does not re-verify a signature the same process just produced. A tampered entry is still verified in full. The cache is not a skip for anything that fails.

Search, copies, and the build

Vector insert is O(1) by id. It used to scan. Search selects the top k instead of sorting the whole set. That is the 83.8 percent drop on ir_vector, and it is the path that matters when retrieval stays on the node. RAG Converter already keeps document conversion in the tab. SpaceDB is the shelf those chunks can live on, and ragconverter.com is the product that habit ships as. A faster top-k does not move the corpus. The question goes in. The hits come out. The body stays.

Copies were the other quiet tax. Rows are sealed and opened in place. Byte strings serialize as one copy. Buffers move across the engine, the shard store, and the transport seam instead of being cloned at each handoff. Remote CRDT updates are no longer re-encoded into an update log that already holds them. A document that never relays raw updates can opt out with CrdtDoc::new_unlogged.

In the MATA monorepo the SpaceDB crates now build at opt-level = 3 for a native release. The web build stays size-tuned. Embedders still choose their own profile. The table above includes that build change, so do not treat every percent as an algorithm. Some of it is the compiler being allowed to finish the job.

New surface area is additive. Bytes, Collection::contains_key, get_with, WriteTx::put_raw_owned, HeldCapability, KeyDirectory::published_key_is, CrdtDoc::caught_up_state_vector, SyncMessage::decode_ref, Transport::send_owned, and ShardStore::put_owned all arrived with default implementations where a trait grew a method. Existing implementors still compile.

What embedders should do with SpaceDB 0.7.0

Pin spacedb-sdk 0.7.0 in an application and leave the default allocator on. rusty_alloc is there so a memory bug aborts instead of silently corrupting a replica the mesh will believe. A library sets default-features = false and lets the binary decide. That rule did not change in this release. The performance did.

MATA.NETWORK is where this database is the durable copy: integrate locally with SpaceDB, distribute on the mesh when the product needs a network it does not already host. The field note is MATA.NETWORK in the wild. Identity on that copy is still a capability you hold, which is mID, not a password in a region. A household that keeps sensor records in the same drawer, cameras and presence that never phone a vendor, is dldeploy.com, and the deployment note is dldeploy in the wild. The map of the bands is Vision.

The Monday test

Bump the crate. Run one authorize, one write, and one read on a local replica, and confirm the value you wrote is the value you read. Then, if you care about the number and not the feeling, build ir_access or ir_sdk in release and count instructions the way the README says: valgrind callgrind on Linux, with randomness pinned so the count repeats. If your own hot path is a range scan or a top-k over vectors that stay on the node, those are the drivers that match the work. Do not quote 98.9 percent as "the database is 98.9 percent faster" on a clock. Quote it as the SDK driver doing the same 330 operations in 12.2 million instructions instead of 1,136.6 million.

Where to look next

What is SpaceDB, SpaceDB, the California essay, source Remade-With-Rust/spacedb, crate spacedb-sdk 0.7.0, mesh home mata.network, local documents ragconverter.com, household sensors dldeploy.com. Reporting on the rebuild lives at futureweb.news.

FAQ

Quick answers for builders evaluating this technology.

Is SpaceDB 0.7.0 a wall-clock speedup?

The published table is exact instruction counts from callgrind, not a clock. A change was kept only when the count fell and the driver's printed values stayed identical. Treat 58.3 percent as less work, then measure your own latency.

Which SpaceDB 0.7.0 driver dropped the most instructions?

The SDK driver, authorize plus write plus read across 330 operations, fell from 1,136.6 million instructions to 12.2 million, a 98.9 percent drop. Access, query, and vector search are the next largest cuts.

Did SpaceDB 0.7.0 change what a replica returns?

The performance drivers were required to print the same values. Two behaviors did change on purpose: a presence check no longer decrypts a document, and a signature the process already verified is not verified again.

Which spacedb-sdk version should an application pin?

spacedb-sdk 0.7.0, published on crates.io on 10 October 2026. Libraries should set default-features to false so they do not force the process-wide allocator onto every downstream binary.

Where is the SpaceDB 0.7.0 measurement written down?

In the Performance section of the SpaceDB README on GitHub. Each crate has an examples/ir_*.rs driver. On Linux, build the example in release and run it under valgrind callgrind.