# Neo4j & Graph Databases: Index-Free Adjacency and Cypher

Try writing "find people connected to this person through up to six degrees of friendship" in SQL and you'll feel the wall immediately: six self-joins, exploding intermediate results, and a query that crawls more slowly the more data you have. The relational model is superb at sets and aggregates, but relationships — the connections between things — are exactly what it represents most awkwardly, as foreign keys you reconstruct with a join every single time you traverse them. Graph databases exist because for some problems the *relationships are the point*, and they deserve to be first-class.

Neo4j is the best-known of them, and the reason it can answer that six-degrees question quickly comes down to one internal design choice: **index-free adjacency**. I'll cover the property-graph model, why that storage trick makes traversal scale completely differently from joins, the Cypher query language, and — importantly — when a graph is the right tool and when it absolutely isn't.

## The property graph model

A graph database stores data as a **property graph**, made of just two kinds of things plus annotations:

- **Nodes** — the entities (a Person, a Product, a Bank Account). Nodes carry **labels** (their type) and **properties** (key-value attributes like `name`, `age`).

- **Relationships** — the connections (`FRIEND_OF`, `PURCHASED`, `TRANSFERRED_TO`). Crucially, relationships are **first-class**: they have a type, a direction, and their own properties (a `TRANSFERRED_TO` can carry `amount` and `date`).

That last point is the conceptual shift. In a relational schema, a relationship is implicit — a foreign key, or a join table you assemble at query time. In a graph, a relationship is a stored object you can attach data to and traverse directly. The data model matches how we actually draw these problems on a whiteboard: circles and arrows, where the arrows matter as much as the circles.

```mermaid
graph LR
    A["(:Person name: Alice)"]
    B["(:Person name: Bob)"]
    C["(:Person name: Carol)"]
    P["(:Product name: Camera)"]
    A -->|"FRIEND_OF since: 2018"| B
    B -->|"FRIEND_OF since: 2019"| C
    A -->|"PURCHASED qty: 1"| P
    C -->|"PURCHASED qty: 2"| P
          
```

A property graph. Nodes (people, a product) carry labels and properties; relationships are typed, directed, and carry their own properties. "Which products did my friends buy?" is a short walk along `FRIEND_OF` then `PURCHASED` edges — a traversal, not a multi-table join reconstructed from foreign keys.

## Index-free adjacency: why traversal scales

Here's the internal that makes graph databases worth their existence. In a relational database, traversing a relationship means a **join**: to follow "Alice's friends," the engine looks up matching rows, typically via an index — an operation whose cost grows with the size of the tables (a B-tree lookup is O(log n), and a multi-hop query multiplies these). The more data you have, the slower each hop gets.

Neo4j uses **index-free adjacency**: each node stores direct physical pointers to its relationships and neighboring nodes. Following an edge is a pointer dereference — it costs the same whether the graph has a thousand nodes or a billion, because you never search; you just walk. Traversal is therefore **O(1) per hop**, dependent only on how many edges you actually follow, not on the total graph size. That's the whole game: a six-hop query touches only the local neighborhood it walks through, while the equivalent six-way SQL join scans and matches against the full tables at every step.

The clean way to hold the difference: **a relational join searches for matches; a graph traversal follows pointers it already has.** This is why a query that's merely slow in SQL at small scale becomes *impossible* at large scale — the join cost compounds with data growth — while the same query on a graph stays fast because its cost is tied to the answer's size, not the database's size. When you hear "deep relationship queries," that's the asymmetry being described.

## Cypher: querying by pattern

You don't traverse a graph with loops; you describe the **pattern** you're looking for and let the engine find it. Neo4j's query language, **Cypher**, is built around ASCII-art that literally looks like the graph: nodes in parentheses, relationships in brackets with arrows. It reads remarkably close to the question:

```text
// "Which products did Alice's friends buy?"
MATCH (alice:Person {name: 'Alice'})-[:FRIEND_OF]->(friend)-[:PURCHASED]->(p:Product)
RETURN friend.name, p.name

// Variable-length traversal: people within 1–4 hops of Alice
MATCH (alice:Person {name: 'Alice'})-[:FRIEND_OF*1..4]->(reachable)
RETURN DISTINCT reachable.name
```

The `*1..4` is the tell — **variable-length path matching** is a first-class operator, expressing "between one and four hops" in a few characters. Writing that in SQL means a UNION of self-joins or a recursive CTE that degrades badly. Cypher makes the queries graphs are good at also *easy to write*, which matters: a tool that's powerful but unreadable doesn't get used. (The industry is, around now, beginning to standardize a common graph query language, GQL, drawing heavily on Cypher.)

## When a graph wins — and when it doesn't

Graph databases are a sharp tool, not a general-purpose one, and matching them to the right problem is the whole skill. They win decisively when **the relationships and their traversal are the core of the question**:

- **Fraud detection** — finding rings: accounts connected through shared devices, addresses, or rapid transfer chains (a multi-hop pattern that's the definition of a graph query).

- **Recommendations** — "people who bought what your connections bought," collaborative paths through a purchase graph.

- **Network and IT topology** — impact analysis: "if this switch fails, what downstream depends on it?"

- **Knowledge graphs** — entities and their relationships as a queryable web, increasingly the backbone of richer search and (looking ahead) retrieval for AI systems.

**Don't make a graph database your system of record for everything.** The failure mode is using a graph for workloads it's bad at: large aggregations ("total revenue by month across all orders") scan huge swaths of the graph and a columnar [warehouse](bigquery-internals-dremel) will crush it; high-volume transactional CRUD is better served by a relational store; and horizontal scaling of a densely connected graph across machines is genuinely hard (you can't cleanly partition something whose value is its connectedness). The right pattern is usually a graph *alongside* your other stores — pointed at the specific relationship-heavy questions — not in place of them. Use it for traversals; keep aggregates and bulk transactions where they belong.

One more positioning note: the property graph (Neo4j, Cypher) isn't the only model — RDF triplestores with SPARQL serve a more standards-and-semantics-driven world (linked data, ontologies). For most application and analytics use cases the property-graph model is the more pragmatic, more performant choice; reach for RDF when interoperable, formally-defined semantics are the actual requirement.

## What to carry away

Graph databases make **relationships first-class**. The **property-graph model** (labeled nodes and typed, directed, property-bearing relationships) matches how connected problems are actually shaped, and **index-free adjacency** is the internal that makes them worth it: relationships are stored as direct pointers, so traversal costs O(1) per hop regardless of total size — exactly where relational joins, whose cost compounds with data growth, fall apart. **Cypher** makes those traversals readable, with variable-length paths as a first-class operator.

Reach for a graph when the question *is* the relationships — fraud rings, recommendations, topology, knowledge graphs — and keep bulk aggregations and high-volume transactions in the stores built for them. Used that way, a graph answers questions that are slow-to-impossible elsewhere. It's also the substrate beneath knowledge-graph-driven AI: the same traversals power [GraphRAG](graphrag) and the [graph-backed retrieval](rag-bedrock-neptune) that vector search alone can't do.