Graph Databases (and the Family Photo)

The last family in the tour is for data where the connections are the point — who follows whom, what leads to what, which regular tends to come with which other regular. A graph database stores those connections as first-class things and answers questions like "friends of friends of friends" in a way that relational JOINs can technically manage but practically groan under. Neo4j is the name. And once its portrait is drawn, the chapter closes with a family photo of everything you've met.

Nodes and Edges

A graph is made of two things. Nodes are the things — a customer, a film. Edges are the connections between them — "Anna FOLLOWS Marta", "Marta ATTENDED Night Bus". Both can carry a little information of their own (when the follow happened, which seat the attendance was). Draw it and you don't get a table; you get a web — dots joined by labeled lines. In a graph database the schema is that web, and connections aren't derived by matching ids later — they're stored directly, as themselves.

The Depth Problem, Honestly

Relational databases handle relationships perfectly well — pointing was the whole of Chapter 2. Where they groan is depth. Ask "who does Anna follow?" and it's a clean one-step lookup. Ask "friends of friends of friends" — three steps out — and in SQL you must join the follows table to itself, once per level:

SELECT f3.followed_id
  FROM follows f1
  JOIN follows f2 ON f2.follower_id = f1.followed_id
  JOIN follows f3 ON f3.follower_id = f2.followed_id
 WHERE f1.follower_id = 214;

Three levels, three joins. Go to six levels and the query is a monster; go to "as deep as it takes" and you can't write it at all, because you don't know the depth in advance. A graph database walks the edges directly, and depth is just a number you write in the query:

MATCH (a)-[:FOLLOWS*1..3]->(b) WHERE a.id = 214 RETURN b

The *1..3 says "follow the FOLLOWS edges, one to three hops out". Change it to *1..6 and you've asked for six levels without rewriting anything. Depth that turns SQL into a monster is, for a graph database, a parameter.

Think of a detective's corkboard: photos pinned up, red string running between them. The insight is never in a single photo — it's in the string, and the detective's native move is "what connects to this, three strings out?" A graph database is that corkboard made queryable. The analogy has done its work, so back to the real terms.

When Graphs Earn It

Graphs earn their place wherever the question is about connections traced through many hops: recommendations ("regulars who attend what you attend"), fraud rings (accounts linked through shared details), org charts, delivery routes, permission chains. Anywhere you find yourself asking "what's connected to this, and to that, and onward" — that transitive reaching is the graph's home.

And, one last time, the refrain: everything else the Marquee does is not this. Booking a seat, listing tonight's screenings, counting a film's sales — none of them trace connections through many hops, so none of them want a graph. The graph is a specialist you add when a genuinely connection-shaped question arrives, not a replacement for the core.

The Family Photo

Here is the whole chapter in one image. The Marquee's core — films, screenings, customers, bookings — lives in the relational database, the source of truth. In front of the homepage sits the key-value cache, serving "tonight's screenings" from memory. Beside the films sits the search engine, holding its copy of the text so the search box can forgive typos. And a future "regulars who attend together" feature would sit on a graph. One business, four families, each doing the one job it's best at, all arranged around a relational heart. The professional name for running several database families together like this is polyglot persistence — right tool, each job — and it is the mature shape of a real data layer, not a sign of indecision.