Cypher Execution Simulator

The simulator

A Cypher query is not one thing. It becomes an AST, a set of planner alternatives, a physical operator pipeline, page cache lookups, store record reads, heap allocations, and sometimes lock waits. This simulator keeps those layers synchronized so the causal chain is visible.

MATCH (e:Entity)-[:HAS_ENUM]->(x:Enum)
WHERE e.externalId = 'ABC-123'
RETURN x.name

Workload knobs

Change the graph shape and cache pressure, then run the same query again. The model is deliberately approximate, but the direction is the point: supernodes inflate relationship expansion, cold cache turns DB hits into disk reads, and dense relationship groups change the traversal shape.

Event log and estimates

The canvas is the visual trace. The readout below is the same simulation as a checklist: which stage is active, what it contributes, and what the approximate final cost model predicts for the current graph shape.

How to read the trace

The top row is the logical query pipeline: parser, planner, execution, storage, memory, locks, and disk. The panels below it are the machine consequences. When the index stage lights up, GBTree pages and page-cache blocks light up. When relationship expansion lights up, the relationship chain or relationship group directory shows the exact reason DB hits rise.

• DB hits are logical store accesses. They can be cheap if the page is already cached.
• Page faults are the expensive part: a page was not in cache and had to be read from disk.
• Relationship groups appear when the node is dense, replacing one long mixed chain with type-specific entry points.
• Heap grows from transaction state, rows, temporary maps, and runtime objects; the GC freeze marker shows why allocation still matters for read queries.
• Locks are quiet for this read trace until you enable the deadlock demo, which turns the same graph into a wait-for graph.

Model limits

This is a pedagogical simulator, not a Neo4j kernel emulator. Real costs depend on runtime statistics, version, store format, indexes, transaction state, record locality, OS cache, concurrency, and the selected runtime. The simulator is useful because it preserves the important causal shape: query form affects operator choice, operator choice affects store access, store access affects page-cache pressure, and page-cache pressure affects latency.

Takeaways

• Query plans are physical. Every operator eventually becomes page and record accesses.
• DB hits are not disk reads. The page cache decides whether the hit is cheap or expensive.
• Supernodes are shape problems. Relationship groups help, but traversal volume still matters.
• Deadlocks are graph problems too. The wait-for graph makes the cycle visible.