Relational join demo: joins as traversal, no planner
You are looking at Bitcoin value-flow graph1.8M nodes · 7.37B edges in one Semurg substrate. Ask it to run a star join, or trace a coin through the chain and it runs the
real query live on this box, on data you can
download and re-run yourself.
Click an example in the agent rail, or ask for a star join, or recursive 4 for a 4-hop fund-trace. Every run is measured end to end, on
this box, on the real dataset. Nothing is pre-computed.
The live Bitcoin value-flow graph stored as 64-byte containers. A join is one edge follow: the multi-way value-flow join is a neighborhood fan-out, the recursive fund-trace is a k-hop walk. No join-order planner, no per-side index, no recursive CTE, no exploding intermediate. Measured live.
the relational query planner
THE INTERMEDIATE EXPLODES. A wide multi-way join needs the right composite index per side and a hand-picked join order, and a recursive fund-trace needs a CTE that re-scans and re-joins the table once per level, until the intermediate result blows up.
semurg, one engine
A join is following an edge. The star join is a one-hop fan-out, the recursive join is a k-hop walk, and the reachable set stays Rust-resident behind a token, so only its count crosses back. No planner, no index, no CTE.
It stays fast at every join width and every recursion depth, where the planner falls off a cliff.
Live Bitcoin value-flow graph: 188.97M tx/address nodes, 684.24M value-flow edges, parsed straight off the Bitcoin P2P network. Measured live on this box. Re-run it yourself.
ask the agent for a "star join" (multi-way fan-out) or "recursive 4" (a 4-hop fund-trace)
A relational engine, once someone hand-builds the right composite index per side and hints the join order, can serve its one shaped query fast, and we do not dispute that. Cold and warm are both shown, measured end to end on the live Bitcoin value-flow graph straight off the P2P network, and the same substrate also serves key-value, full-text and vectors.