In this chapter
We'll close honestly on graph performance, indexing, dense nodes, traversal complexity, and when a graph database is the wrong tool for the question being asked.
The Problem in Real Life
Mike likes the recommendation engine, then asks the question every honest chapter in this course eventually earns: does any of this actually stay fast once the graph is huge, and are there times GreenMart shouldn't reach for a graph at all?
Both are fair. Traversals are powerful, but they aren't magic — and this Act closes the same way every earlier one did, by being honest about the cost.
This all makes sense on a small graph. Does it still work once ours is huge?
Mike
What Traversals Cost, and When to Skip Them
Dense nodes are this Act's hot-key lesson
A node with enormous relationship count can slow traversals through it — the same shape as Redis's hot keys and DynamoDB's/Cassandra's hot partitions.
Not always the right tool
When questions are mostly about individual records, not relationships, a graph adds complexity a document or relational model doesn't need.
Graph Performance & When Not to Use One
Three real questions hide inside Mike's one: how fast is a traversal at real scale, what specifically slows one down, and — the honest close — when should GreenMart not use a graph database at all?
- On finding a starting point. Graph performance depends heavily on graph indexing — a database still needs a fast way to find a starting node before it can traverse from it at all, the same lookup problem every earlier Act has had its own answer for. Without an index on, say, product name, even the very first step of a traversal means scanning every node.
- On one node slowing everything down. A dense node (sometimes called a supernode) is one node with an enormous number of relationships — like a wildly popular product every customer has bought. Traversing through it can be slow, the same underlying shape as Redis's hot keys, DynamoDB's hot partitions, and Cassandra's own hot partitions, now showing up a fourth time in a fourth product.
- On depth. Traversal complexity grows with how far a query has to walk: a shortest-path search across a small, well-modelled graph is fast; the same search across a huge, densely-connected one, several hops deep, can genuinely get slow — each additional hop means following every relationship out of every node reached so far.
Which leads to the honest close of this whole Act: when graph databases are a bad choice. If GreenMart's actual questions are mostly about individual records — this order's total, this customer's address — a graph adds real complexity for no real benefit; a document or relational model stays simpler and just as fast. Graph databases earn their place specifically where relationships are the interesting part of the question, at a depth a join can't practically reach — a fraud ring, a recommendation, a knowledge graph. Graph vs. relational modelling, in the end, isn't "which is better" — it's the same question this entire course keeps returning to: what does GreenMart actually need to ask, and which database makes that specific question cheap?
Key Takeaway
Dense nodes and deep traversals aren't free, which is exactly why a graph database earns its place only where relationships are genuinely the interesting part of the question — not by default, and not everywhere.
Why This Matters
A graph database chosen for the wrong reason — because relationships sound interesting, not because GreenMart's real questions actually need deep traversal — costs real complexity with no real payoff. This chapter is what turns "graphs are powerful" into an honest, specific decision about when that power is actually worth it.
GreenMart now has a clear, honest answer for when a graph is — and isn't — the right tool. The checkpoint ahead asks Sarah — or you — to trace GreenMart's actual fraud ring from scratch, with every one of this Act's lessons made on purpose.