Collapsive architecture
Not the query.
The stack.
A pointer-and-index engine spends its life chasing references around memory. Tetra does not chase them at all. Once nothing is chasing pointers, whole layers of the stack have nothing left to do: no index to maintain, no cache to warm, no cluster to babysit. That is what collapses.
The collapse, drawn
Same stack. Two shapes.
A graph stack today
- Your application
- Cypher, over Bolt
- Index layer
- Page cache
- Storage engine on a JVM heap
- Replicas, and a cluster to coordinate
- Warm-up, tuning, capacity planning
The same stack, on Tetra
- Your application unchanged
- Cypher, over Bolt unchanged
- The Tetra engine one binary · one file
Every layer that disappeared had the same job: finding things quickly in a structure built for chasing pointers. Change the structure and the job stops existing, so there is nothing left to maintain, warm, or babysit.
What disappears, and why
Open a layer.
Five layers of a classic graph stack, and the honest reason each one stops existing on Tetra.
The index layer goes away
An index exists to find things quickly in a structure built for chasing pointers. Change the structure and there is nothing to index — so there is no index to build, size, or keep in sync.
The page cache goes away
A cache warms hot data into memory because cold reads are the bottleneck. When the engine isn’t chasing references around memory, the bottleneck it existed to hide isn’t there, so neither is the cache.
The storage engine on a JVM heap goes away
The classic design keeps the working set resident and pays for it in heap tuning and page-cache math. Tetra is a single file on disk with none of that ceremony — no heap to size, no GC to chase.
Replicas, and a cluster to coordinate goes away
You scale a memory-resident engine by adding machines and coordinating them. With the memory pressure gone, the reason to shard and replicate for RAM headroom goes with it — one binary, one file.
Warm-up, tuning, capacity planning goes away
All of the operational work above has the same root — keeping a large graph fast in memory. Remove that job and the runbook mostly empties out: there is nothing to warm, tune, or size ahead of.
How we change the structure is math, and the math is ours for now. It is the one thing we’re not publishing yet — so the benchmarks ship with their datasets and reproduction steps instead, and you’re welcome to watch it run on a graph of your own.
Where the shape fits
- Graph workloads that outgrew their engine. The RAM bill is the roadmap.
- Products that must ship the database inside them. Edge, air-gapped, on-prem.
- Teams stranded by an embedded graph DB going away. Cypher-compatible, so the port is short.
- Anyone whose graph is the product, and whose margins are the engine’s.