Graph databases: modeling and querying connected data
When your questions are about relationships — who cites whom, what connects to what — a graph database answers them directly. Here's how Neo4j/Cypher and Neptune/Gremlin model and traverse connected data, and the traps.
Relational databases store relationships as foreign keys and reconstruct them with joins — which gets painful when the question is 'follow these connections several hops out'. A graph database stores relationships as first-class citizens, so traversing them is the fast path, not the slow one. This is different from GraphRAG (which is retrieval for an LLM); here we're talking about the datastore itself.
Nodes, relationships, and the query languages
A property graph is nodes (entities) and relationships (typed, directed edges), both carrying properties. Neo4j with Cypher is the common choice — its pattern-matching syntax reads like ASCII art of the graph — while AWS Neptune speaks Gremlin (and also supports SPARQL). You model by asking what you traverse: the relationships you query most become explicit edges, and you add property indexes on the fields you start traversals from.
Traversal and the supernode problem
The power is multi-hop traversal: 'find inventors of patents that cite patents assigned to company X' is a walk across edges, and a graph does it without the exploding joins a relational store would need. The classic trap is the supernode — a single node with millions of relationships (a hugely-cited patent, a prolific assignee). Traversing through it is catastrophically expensive, and the fixes are modelling ones: partition the hot relationships, add intermediate nodes, or filter early so you never fan out through the supernode.
A worked domain: patents
Connected domains are where graphs shine. A patent corpus models naturally as a graph: patents linked into families and continuations, forward and backward citations as directed edges, inventors and assignees as nodes, the CPC/IPC classification as a hierarchy, and litigation as links between parties and patents. Questions like 'what's the citation lineage of this claim' or 'which assignees are two hops from this litigation' are traversals — awkward in SQL, native in a graph.
When to reach for one
Use a graph database when relationships and multi-hop questions are the core of the workload and provenance matters. Don't use one as your primary transactional store for tabular data — that's still Postgres's job. In practice a graph is one store among several (see the polyglot-persistence post), holding the relationship layer while other stores hold documents, vectors, and rows.
In a relational store, relationships are something you reconstruct with joins. In a graph, they're the thing you stored — which is why the questions that are really about connections finally get cheap.