What Is a Graph Database and When to Use Neo4j

The short answer

A graph database stores data as a graph rather than as tables:

• nodes — entities: a user, a product, a company, a card;
• edges (relationships) — directed connections between nodes: "friends with", "bought", "reports to", "used";
• properties — key-value pairs on both nodes and relationships: name, date, amount.

Nodes carry labels (:User, :Product), and relationships have a type (:BOUGHT). The best-known graph database is Neo4j, and its query language is Cypher.

The key difference: a relationship is not a JOIN computed at query time but a stored object. From any node you can step straight to its neighbours without matching keys across a whole table.

Why relationship chains are hard in SQL

In a relational database, a relationship is a foreign key, and every hop through the graph is another JOIN. One or two hops are fine. Trouble starts when:

• depth is unknown in advance — "find everyone connected to this account through any number of transfers";
• there are many hops — "friends of friends of friends";
• relationships are mixed — user, device, phone, card and address in one chain.

SQL handles this with recursive CTEs (WITH RECURSIVE). They work, but they are hard to read, intermediate rows can explode, and the planner struggles to estimate their cost. In a graph database, traversal is the core operation, and a query is written as a path pattern.

Where graphs are a natural fit

A Cypher example

Recommending "friends of friends you do not know yet":

MATCH (me:User {id: 42})-[:FRIEND]->(friend)-[:FRIEND]->(candidate)
WHERE candidate <> me
  AND NOT EXISTS { (me)-[:FRIEND]->(candidate) }
RETURN candidate.name, count(friend) AS mutual
ORDER BY mutual DESC
LIMIT 10

The query reads almost like a drawing: from me, through a friend, to a candidate. And here is finding accounts linked within four hops through any shared object:

MATCH (a:Account {id: 'A-1'})-[*1..4]-(linked:Account)
RETURN DISTINCT linked.id

In SQL, the same thing needs a recursive query with manual cycle protection.

When PostgreSQL is still the better choice

A graph database is a specialised tool. Stay with PostgreSQL when:

• your core data is tabular: orders, payments, stock, invoices;
• you need aggregates and reports: sums, grouping, exports for accounting;
• relationships are shallow and known in advance — one or two indexed JOINs are fast;
• the hierarchy is small — an org chart of a few hundred people is easy with WITH RECURSIVE;
• the team has no graph experience, and a second database means more backups, monitoring and syncing.

A common working setup is a hybrid: PostgreSQL stays the main database, and the graph database receives a copy of the relevant relationships for recommendations or fraud checks.

How to decide

1. Write down the 3–5 most important queries your product runs.
2. If most are about totals, filters and lists, a relational database fits.
3. If the key queries are about paths, neighbours and variable-length chains, prototype on a graph.
4. Test on realistic data volumes before moving anything to production.

Common mistakes

• Moving the entire system into the graph, payments and reporting included.
• Modelling everything as node properties and forgetting relationships — the graph becomes a slow table.
• Running unbounded traversals ([*]) on large graphs.
• Not planning synchronisation when the graph is a copy of the main database.