Home

Project Manifold

A native graph extension for SpacetimeDB, built in two stages:

• Stage 1 (this fork) — A userland graph module using the existing reducer/procedure API. No engine changes. Proves the approach and characterizes the performance ceiling.
• Stage 2 (planned) — Native engine-level graph support: index-free adjacency traversal, Cypher-to-RelExpr translation, and real-time subscription integration.

Why a graph extension?

SpacetimeDB is a relational database with a real-time subscription layer. Modern applications increasingly model connected data — social graphs, recommendation engines, knowledge graphs, fraud detection. SpacetimeDB's existing SQL engine can handle graph workloads, but the developer experience and performance leave room for improvement when graphs grow beyond toy scale. Project Manifold asks: can SpacetimeDB do graphs well? And if so, how deep into the engine do we need to go?

The two stages

Stage 1 — Userland ceiling

We built a Wasm module (graph-module) that adds vertices, edges, and graph traversal (BFS, DFS, shortest path) as first-class operations. Under the hood: a new GraphId SATS type wired through the full type system, a shared graph-algo crate with cycle-safe traversal algorithms, and procedure-based queries that run outside the transaction lock. See: Stage 1

Stage 2 — Engine integration

Stage 2 moves from userland to the engine. Planned: native GraphId in the client codegen path, graph-aware physical plan operators for index-free adjacency traversal, Cypher query translation, and incremental graph query evaluation under the subscription layer. See: Stage 2

Benchmark results at a glance

We compared SpacetimeDB against Neo4j and Apache AGE on three SNAP datasets. SpacetimeDB's userland module matches or beats Neo4j on small-to-medium graphs, and holds within 5x on the 4M-vertex LiveJournal dataset — all with zero engine changes. See: Benchmarks