Joins don't scale
You run a movie site. Someone asks: "Who are Kevin Bacon's co-stars?" In SQL that's a join from person to roles to movie to roles back to person. "Co-stars of co-stars"? Two more joins. Four hops out and you have a five-table self-join and a DBA who has stopped returning your calls.
The core claim of this whole course, stated boldly: in a relational database each join hop is an index lookup that gets more expensive as the table grows (≈ O(log n)); in a graph database each hop is following a pointer you already have (O(1)) — independent of how big the database is.
The same question, two ways
SQL (relational): GRAPH (pointer-chase):
person ⨝ role ⨝ movie ⨝ role ⨝ person bacon ──ACTED_IN──▶ A Few Good Men
4 joins, each an index probe ◀─ACTED_IN── Tom Cruise
cost grows with table size follow 2 pointers. done.
Here's the analogy to carry the whole way: a relational join is looking someone up in the phone book every single time. Index-free adjacency — the structure you'll build in Chapter 2 — is having their phone number already written on a sticky note stuck to your monitor. The graph database paid the cost once, when the relationship was created. The relational database pays it every query.
Over the next ~40 steps you'll build, in the order a real graph database is built: a record store for nodes and relationships, then index-free adjacency (the structure that makes a hop O(1)), then label and property indexes (to find where to start), then the traversal algorithms (BFS, DFS, shortest path, variable-length), and finally a Cypher-lite query engine — tokenizer, parser, executor — on top. The finale: your own kgdb query answers the Bacon co-star question on the vendored Movies graph.