Graph Model

Overview

The graph data model represents data as nodes (vertices) and edges (relationships) connecting them, where both nodes and edges can carry their own properties (this specific variant is called a property graph, the model used by Neo4j, Amazon Neptune, and others). Unlike every other model in this chapter, relationships here are treated as first-class citizens with equal importance to the entities they connect — not an afterthought expressed via foreign keys or embedding.

How it works — a worked example

A social network fragment:

(Alice:Person {age: 29}) -[:FRIENDS_WITH {since: 2019}]-> (Bob:Person {age: 31})
(Bob:Person) -[:FRIENDS_WITH {since: 2021}]-> (Carol:Person {age: 27})
(Alice:Person) -[:WORKS_AT]-> (Acme:Company {industry: "Tech"})

To find "friends of Alice's friends who don't already know Alice" (a classic recommendation query), Neo4j's Cypher query language expresses it declaratively and efficiently:

cypher
MATCH (a:Person {name:"Alice"})-[:FRIENDS_WITH]->()-[:FRIENDS_WITH]->(fof)
WHERE NOT (a)-[:FRIENDS_WITH]->(fof) AND fof <> a
RETURN fof

The key architectural reason this is fast is index-free adjacency: each node physically stores direct pointers to its adjacent edges, so traversing "friend of a friend" is a constant-time pointer hop per edge, regardless of total database size — a relational database would need an expensive multi-way self-join on a friendships table that gets slower as the table grows.

Edge cases and trade-offs

• Multi-hop traversals are the graph model's superpower: queries like "shortest path between two people," "friend of a friend of a friend" (arbitrary-depth traversal), or fraud-ring detection (cycles of suspicious transactions) are natural and fast in a graph database but require increasingly expensive recursive joins in a relational database.
• Poor fit for simple aggregate/tabular reporting: "total sales per region last quarter" is a trivial GROUP BY in SQL but awkward and unnatural to express as a graph traversal — graph databases are not a general replacement for OLAP-style rollups.
• Schema flexibility: new node labels, relationship types, and properties can be added at any time without a migration, similar to the document model's flexibility, but structured around connections rather than nested documents.
• Scaling graph databases horizontally is genuinely harder than scaling key-value or column-family stores, because a highly interconnected graph resists clean partitioning (a "cut" across the graph inevitably severs some edges, forcing cross-node traversal); this is an active area of engineering trade-offs.

How this differs from the legacy Network Model (3.2)

Both use "nodes and connections," but they are not the same thing:

• The network model (CODASYL, 1970s) requires relationships ("sets") to be predefined in a rigid schema and traversed with procedural DML code written by the programmer.
• The modern graph model (property graphs) lets you add new relationship types on the fly with no schema migration, and is queried with a declarative language (Cypher, Gremlin) where you describe the pattern you want matched, not the step-by-step pointer-chasing to get there — plus it natively attaches properties to both nodes and edges, which CODASYL sets do not support.

Key takeaways / interview Q&A

Q: What is "index-free adjacency" and why does it matter? A: Each node stores direct references to its connected edges/nodes, so traversing a relationship is a cheap, constant-time pointer hop rather than an index lookup or join — this is what makes multi-hop graph traversals fast regardless of overall database size.

Q: When would you explicitly choose a graph database over a relational database? A: When the core value of your queries comes from traversing relationships of variable/unknown depth — social networks, recommendation engines, fraud detection, knowledge graphs — rather than from tabular aggregation or simple lookups.