Graph database
A database built to follow relationships across many hops, such as friends of friends or dependencies of dependencies.
See it
What it is
A graph database stores entities as nodes and relationships as edges, usually with properties on both. Its strength is traversal: start at a person, follow WORKS_WITH edges, then follow EMPLOYED_BY, without planning a growing chain of SQL joins in advance. Neo4j's Cypher query language makes that path-shaped model explicit.
Reach for one when relationships are central to the questions: fraud rings, dependency graphs, recommendations, network topology, access paths, or friends of friends. Six Degrees of Kevin Bacon is that shape exactly: a path of unknown length through a network of people. A relational database still handles known, shallow relationships well. The graph earns its keep when paths vary in length and traversing them is the normal workload.
Gotcha: drawing circles and arrows does not make every dataset a graph database problem. Global scans and ordinary reporting may be less natural, and a supernode with millions of edges can turn one traversal into a huge fan-out. Put constraints on identity, give every edge a clear direction and meaning, cap traversal depth, and inspect query plans instead of assuming graph syntax makes an expensive path cheap.
Ask AI for it
Model this fraud-investigation dataset in Neo4j with labeled Customer, Account, Device, and Transaction nodes plus explicit OWNS, USED, SENT_TO, and RECEIVED_BY relationships. Add Cypher uniqueness constraints for external IDs and indexes for the starting lookup fields. Write parameterized Cypher queries that find accounts sharing a device within three hops and use shortestPath only with a bounded relationship pattern. Return paths with evidence fields, inspect each query with PROFILE, and add limits that prevent supernodes from causing unbounded fan-out.