When a graph database beats relational or document stores

WHY THIS QUESTION It tests whether you choose a data store from access patterns rather than hype, and whether you understand the mechanical reason graphs excel at traversals.

A GOOD ANSWER COVERS Scenarios dominated by relationships: fraud detection finding rings of shared accounts or devices, social networks computing friends-of-friends, recommendation engines following people-who-bought paths, identity and access graphs, and dependency or impact analysis. The query pattern is variable-depth traversal, often unbounded, where you follow edges from a starting node. Graph engines use index-free adjacency: a node stores direct pointers to adjacent nodes, so expanding a neighborhood is a constant-time pointer hop per edge and the query cost scales with the result subgraph, not the total node count.

CONTRAST WITH ALTERNATIVES In a relational database the same traversal becomes a join per hop. A five-hop friend query needs five self-joins, and the optimizer must scan or index-probe at each level, so latency and intermediate result size grow quickly with depth. Document databases force you to either embed and duplicate or do application-side fan-out reads.

LIKELY FOLLOW-UPS What is index-free adjacency, how does Cypher express variable-length paths, when would you not use a graph database, and how do you handle supernodes with millions of edges.

ONE CONCRETE EXAMPLE A fraud team wants accounts that share a phone, address, or device within four hops of a flagged account. In Cypher this is a single variable-length MATCH that returns the ring in milliseconds; the equivalent SQL needs recursive CTEs or stacked joins that blow up combinatorially as depth increases.