Graph Databases (Neo4j)

When the relationships between things matter as much as the things themselves, a graph database models that directly, instead of simulating it with foreign keys and joins. This page is about querying and traversing an existing graph of real entities — a different problem from Graph ML Fundamentals, which is about learning from graph structure (node embeddings, GNNs, predicting a missing edge). A graph database answers "what is connected to what, right now"; graph ML answers "what does this graph's structure imply about a node/edge that isn't directly stored."

The Property Graph Model

Nodes: entities (a person, a document, a product), each with properties (key-value attributes).
Edges: relationships between nodes (e.g. "WROTE," "CITES," "PURCHASED"), which can also carry their own properties (e.g. a "PURCHASED" edge might have a date and amount).

(Ada:Person)
role: researcher

Nodes: ■ Person ■ Document

Click a node to see its properties. Edges carry their own properties too (WROTE has a date) -- both nodes and relationships are first-class, queryable data, not just foreign keys implied by a schema.

Unlike a relational database, where a multi-hop relationship requires a chain of joins that gets slower with each additional hop, graph databases store relationships as first-class citizens — traversing from one node to its neighbors (and their neighbors) is a fast, local operation regardless of how large the overall graph is.

Hops (relationship depth)3

■ Relational JOIN chain■ Graph traversal

At 3 hops: a relational join chain (assuming ~3 matching rows per hop) examines on the order of 27 rows, while a graph traversal touches roughly 6 -- following a relationship pointer is a local, near-constant-time step regardless of how large the overall graph is, while each additional JOIN multiplies the previous step's result set.

Neo4j and Cypher

Neo4j is the most widely used graph database, queried with Cypher, a declarative query language designed to read like a visual description of the pattern you're looking for — e.g. matching "a person who wrote a document that cites another document written by a different person" reads almost like an ASCII-art sketch of that pattern:

MATCH (p1:Person)-[:WROTE]->(d1:Document)<-[:CITES]-(d2:Document)<-[:WROTE]-(p2:Person)

This one query pattern reads almost like a sketch of the shape you're looking for: a person, connected by WROTE to a document, connected by CITES to another document, connected by WROTE to a different person. The equivalent in SQL would be a 3-way self-referencing join across a people table and a citations table -- readable, but nowhere near this direct.

When a Graph Model Beats Relational

Graph databases shine specifically for highly connected data and multi-hop queries: social networks (friends-of-friends), fraud detection (tracing chains of related transactions/accounts), recommendation via relationship paths ("people who bought what you bought also bought..."), and knowledge graphs. If your queries are mostly "get me this entity and its direct attributes," relational is simpler and faster; if your queries are mostly "find all the ways these entities are connected," a graph model is a much more natural fit — see Relational Databases for the comparison from the other side.

"Find every way these entities are connected, possibly several hops apart."

Graph database (Neo4j)

Fraud rings, friend-of-a-friend recommendations, knowledge graphs, GraphRAG multi-hop reasoning.

Real systems typically use all three side by side -- Postgres for accounts and transactions, a vector index (or pgvector, inside that same Postgres) for retrieval, a graph database for the relationship-heavy slice of the problem. The question is never 'which one database should this whole system use' so much as 'which store does this specific query pattern belong in.'

GraphRAG

The most directly relevant application to the rest of this curriculum: standard RAG retrieves isolated document chunks, which struggles when an answer requires connecting facts scattered across multiple documents (multi-hop reasoning). GraphRAG first builds a knowledge graph from the source documents (extracting entities and their relationships), and retrieval can then traverse those relationships directly — answering "how are X and Y connected" in a way flat vector similarity search structurally cannot. See RAG — GraphRAG for the full retrieval-pipeline context.

Databases section complete. Next: Frameworks — the concrete tools (PyTorch, LangChain, MCP SDKs) used to build with everything covered so far.