What You'll Master Here
A graph stores entities as nodes and their relationships as first-class typed, directed, attributed edges, so you walk connections instead of joining tables.
Most databases treat a relationship as something you reconstruct: a foreign key, a join table, a join computed at query time. A graph database stores it instead, as a typed, directed object that can carry facts of its own. This chapter is about modelling a domain when the connections between things are the point.
One domain runs through every topic: Kestrel, an open-source package registry where packages depend on packages, maintainers maintain them, and advisories affect version ranges. Start with the map below. It shows the graph and the six decisions that produced it, and each decision links to the topic that makes it.
A graph stores entities as nodes and their relationships as first-class typed, directed, attributed edges, so you walk connections instead of joining tables.
Recommendations, fraud rings, dependency and supply-chain analysis, knowledge graphs and network topology are all questions about paths. Knowing when that shape justifies a graph store, and when it does not, is a senior architecture judgment.
- node
- An entity in the graph, with a label (its type) and properties.
- relationship
- A typed, directed edge between two nodes, which can carry its own properties.
- traversal
- Walking from node to node along relationships to answer a question.
- hop
- One step along a relationship from one node to the next.
- applicationcheckout-api
- frameworkshttp-kitauthgatequeue-riderledger-sdk
- utilitiesjson-liteuri-parselogsigmetrics-tapcryptoboxrandseed
- base librariesbytebuftinyparseclockshim
Reaching for a graph because one query in the system is a traversal. You take on a second database, a second copy of the data, and a sync problem, to speed up a query a recursive CTE already answered.
Ask whether the hard questions are about paths or about totals before choosing a store.
Model relationships as first-class edges, not join tables.
Keep aggregation-heavy analytics in relational or dimensional stores.
In a graph, a relationship is data you store and walk, not a join you compute. That is what makes deep and variable-length questions both natural to express and cheap to run.
Graph databases make relationships first-class so connected, multi-hop questions become traversals; use them when the connections are the point, not for tabular aggregation.