Why a Graph Database

The relational tax on connected questions

How many people, at most 3 friendship-hops away, work at companies founded after 2015? — in SQL this is three or four JOINs plus a recursive CTE. In a property graph it is four lines of Cypher and the engine walks pointers instead of computing Cartesian products.

A property graph has three primitives:

• Nodes — entities (Person, Company, City).
• Relationships — typed, directed edges ((:Person)-[:WORKS_AT]->(:Company)).
• Properties — key/value data on both nodes and relationships.

Neo4j stores relationships as first-class records with direct pointers, so a traversal is O(degree) — not O(table-scan + hash-join).

Think of a relational DB as a filing cabinet: every drawer is a table, every connection requires you to walk to another drawer, read the index, and pull a file. A graph DB is a whiteboard with sticky notes and arrows: each note already points at the notes it relates to. To answer 'who knows whom?' you follow arrows, you don't search other drawers.

A tiny property graph: two Person nodes, one Company, one City — and the relationships that tie them together.