Leyline keeps the graph as immutable CSR segments in S3 and runs traversal on stateless compute. A two-hop query reads two neighbourhoods, not two copies of your graph — so the bill tracks the walk, not the size.
Every vertex's neighbours sit contiguously in one array. offsets[v] and
offsets[v+1] bracket the slice, so expanding a vertex is one read at a
known length — no walking the structure to find the structure. Segments are sealed
at write time, so any reader can cache one forever and no reader ever takes a lock.
A segment is sealed when it lands. Readers never coordinate, never invalidate, and never see a torn view.
Vertices walked together get written together, so most hops land inside the segment they started in.
No cluster to keep warm, no rebalance, no leader election. Traversal fans out per query and then disappears.
A supported subset — MATCH, variable-length paths, WHERE,
aggregation, shortestPath. The planner's unit of work isn't a table scan,
it's a segment fetch, and it names the ones it intends to touch before it touches them.
Graph databases usually price the graph: resident memory for all of it, whether or not you ever query it. Leyline prices the traversal. A graph you don't walk this month costs object storage and nothing else.