Dependency & impact analysis

Every system is a dependency graph pretending to be a wiki. Which services call the one that's about to be deprecated? What breaks downstream if this table changes? Those are reachability questions, and reachability is exactly what a graph answers without a rewrite per hop.

Blast radius is a variable-length path

"What depends on this, directly or transitively" is `[:DEPENDS_ON*1..]` — follow the edges as far as they go. In a relational model the depth is unknown, so you're writing recursive CTEs or fanning out queries in application code. In Cypher the depth is part of the pattern, and the whole downstream cone comes back in one query.

One graph across services, data and people

Model services, datasets, pipelines, dashboards and their owners as nodes, and 'depends on', 'produced by', 'owned by' as edges. Now a single traversal answers cross-cutting questions — who owns anything affected by this migration, which dashboards read a column you're dropping — that otherwise mean stitching together four inventories.

Kept current from what you already emit

Dependency edges usually already exist somewhere — service manifests, dbt lineage, Terraform state, CI metadata. Load them with MERGE so re-ingestion is idempotent, and the graph stays as fresh as its feeds without a person maintaining a diagram.

Everything downstream of a service about to change, with owners.cypher
MATCH (target:Service {name: $name})<-[:DEPENDS_ON*1..8]-(affected:Service)
OPTIONAL MATCH (affected)-[:OWNED_BY]->(team:Team)
RETURN affected.name,
       collect(DISTINCT team.name) AS owners,
       length(shortestPath((affected)-[:DEPENDS_ON*]->(target))) AS hops
ORDER BY hops

Other use cases

Graph memory for AI agents

Give an agent a graph it can traverse instead of a transcript it has to re-read. One instance per agent, per session, or per tenant.

MATCH (a:Agent)-[:REMEMBERS]->(f:Fact)Read more

Knowledge graphs

Model people, documents, systems and the relationships between them, then answer questions that span all of them at once.

MATCH (d:Document)-[:MENTIONS]->(e:Entity)Read more

Multi-tenant graph applications

Give every tenant a real database instead of a tenant_id column. Isolation you can point at, and cost that scales with what each one uses.

CREATE (t:Tenant {id: $tenant})Read more

Dependency & impact analysis

Model what depends on what — services, data, teams — and answer "if this breaks or changes, what's affected?" as a traversal instead of a spreadsheet.

MATCH (s:Service)<-[:DEPENDS_ON*1..]-(affected)Read more

Real-time recommendations

Compute "people like you also chose" live from the behaviour graph at request time — so a purchase a second ago changes the next suggestion.

MATCH (u)-[:BOUGHT]->(p)<-[:BOUGHT]-(peer)Read more

Robotics, hardware & the edge

Model the world a fleet shares — robots, devices, assets, tasks and their dependencies — as one graph the whole fleet can query in real time.

MATCH (r:Robot)-[:CAN_REACH]->(z:Zone)<-[:LOCATED_IN]-(a:Asset)Read more

Start now

~98.7%

token efficiency at 2,000 entities — see the footnotes above

Put your first graph up in a minute.

A free instance takes about a minute and no card. Write two MERGE statements, read them back, and you have a living graph — with provenance on every fact.

Start free View the quickstart

First-graph path

Live

  1. Create a free instance

    No card. Ready in about a minute.

  2. Connect your driver

    bolt+ssc:// URI into the driver you already use.

  3. Write two MERGEs

    That's the entire shape of agent memory.

  4. Point an agent at it

    One MCP config block. No integration code.