The joins your data store
can't do
— in milliseconds.
Because disparate data doesn't
cluster.
Stitch correlates records across your systems on exact keys, answering multi-hop
“what's connected to X” questions that vector search misses and batch
engines are too slow for. Deterministic, auditable, and AI-native.
Real questions cross several relationships — each one a “hop.” Today, every tool in the stack fails them differently.
Vector / RAG
Built for find similar text
Returns the wrong records — 0% recall on 2–3 hop questions, because the answer shares no terms with the query.
Spark / warehouse
Built for batch analytics
Scans and shuffles everything to resolve a selective join — minutes, not the milliseconds a live system needs.
NoSQL stores
Built for fast storage
Mongo, Elastic, and Dynamo can't join across collections at all. You hand-code brittle pipelines instead.
A correlation layer beside your data.
Stitch indexes the exact relationships between records — then resolves any multi-hop question as point lookups, not scans.
01
Register your sources
Point Stitch at the tables and key fields it should correlate on — across one store or many.
02
Build the correlation index
One pass builds the patented index/stitch/map structures that record the exact address of every shared value.
03
Correlate in milliseconds
Ask “what's connected to X” across any number of hops. Bounded point lookups — never a scan.
Distributed · verified against SQL
Joins without the join.
A relational JOIN is the most expensive primitive in analytics —
it's why multi-table questions run as overnight batch. Stitch collapses it: the relationship is computed once, at
index time, so a multi-table join becomes a chain of O(1) lookups —
the answer a SQL JOIN gives, without the scan.
The join is precomputed
At index time, every relationship between records becomes a hash-addressable object. The expensive part of a join happens once — not on every query.
A k-way join is a chain of lookups
Walk customer → order → line-item → product by pivoting on each hop's key. No hash-join, no sort-merge, no scan — just bounded point lookups proportional to the answer.
The same answer SQL gives
Deterministic and exact. Our engine's multi-table joins are verified byte-for-byte against SQLite on the same data — the correctness of a JOIN, at lookup speed.
Live in the engine today: write SQL — SELECT … JOIN … ON … WHERE —
and it compiles to the stitch walk, executed distributed across shards
with node failover, returning results verified byte-for-byte against SQLite. Aggregates and GROUP BY
are next. Proven, not promised — we ship what's built.
Try it live.
Three real public datasets, indexed in Stitch. Write SQL, run it against the live engine, and see — for the very same query — what Stitch does versus what a database without a correlation index has to scan.
Read-only. There is nothing to inject: Stitch's SQL is a whitelist SELECT grammar compiled to point lookups — no writes, no stacked statements.
Datasets: TPC-H (generated), a slice of ICIJ Offshore Leaks, and CTU-13 botnet netflow (Stratosphere IPS).
Four ways this shows up in the real world.
Each is a selective, multi-hop, cross-store question with a human or a transaction waiting.
AI support copilot
customer → orders → shipments → tickets → known issues
Today: Vector RAG returns generic articles, not this customer's actual case.
Stitch: Assembles the exact connected records in ms — clean context for the LLM.
Real-time fraud / AML
card → account → device → other accounts → flagged
Today: Graph DBs are a second system to sync; Spark is batch. Rings are caught the next day, if at all.
Stitch: The multi-hop ring check is a few point lookups — under 50 ms, inline with the transaction.
Security incident response
host → processes → connections → hosts → users
Today: Elasticsearch can't join across indices; analysts pivot by hand while the attacker moves.
Stitch: One correlation expands the full blast radius across log indices in milliseconds.
Product recall / traceability
lot → assemblies → products → shipments → customers
Today: Genealogy is siloed across ERP/MES/WMS; tracing takes days, so recalls are over-broad.
Stitch: Exact affected serials and customers in minutes — surgical recall scope.
Proven, not promised.
Reproducible benchmarks, with the cases where it loses shown honestly.
58,124× faster
at 1 billion log lines — and it stays flat, because Stitch reads your 1M query keys, not the corpus.
100% vs 0%
of multi-hop answers recovered, where vector RAG returns nothing.
4–6 orders
of magnitude faster than Spark on selective and multi-hop joins.
“Which of my 1,000,000 keys are in the corpus?”
O(query‑set), not O(corpus) — measured, single box.
The scan grows with the corpus (1.6 s → 15 s → 178 s); Stitch never moves — it only reads the query keys.
The gap is structural, so it only widens: at 100 B lines a scan is hours, Stitch is unchanged.
Roaring-bitmap hot tier (~3 ms); the dependency-free Set path is ~122 ms — both flat.
A real moat.
Patented mechanism
US 11,151,112 (granted) — a defensible, novel way to correlate non-relational data.
Backend-agnostic
Runs natively on stplr, our open distributed substrate — and on MongoDB, Elasticsearch / OpenSearch, Redis, and more. No new database.
Ships as an MCP toolkit your agents call today — the structured retrieval RAG can't do.
Meet the mascot
This is spndl.
Say it “spindle.” spndl is the spider behind Stitch — it spins exact
threads between records and walks the whole web in a few bounded hops. The multi-hop joins your
data store can't do? That's just spndl following a thread.
◆Spins the index. Every shared value becomes a thread with an exact address — never a scan.
◆Walks the web. “What's connected to X” across any number of hops, in milliseconds.
◆Nests on any store. Happiest on stplr, at home on Mongo, Elastic, and Redis.
