Graph models by industry
Use a graph when the relationship between records matters to the question. These examples follow account links, purchase connections, part dependencies and reporting lines. They are illustrative models; adapt the relation and limits to your own data.
- Start with a flagged accountIdentify the record being investigated.
- Choose a declared relationshipFor example, accounts linked through a shared device.
- Follow a bounded pathLimit the relations and number of hops.
- Inspect the connected recordsReview the underlying activity before reaching a conclusion.
Financial services: finding a fraud ring
Individually ordinary accounts, connected in a way that is not. The signal is the shape, not any single row.
The relation
fin.transfers (id PK, from_account, to_account, amount_minor, at)
relation: "to_account" -> fin.accountsWho is within three hops of a flagged account
A ring shows up as a small set reachable in a few hops and reaching back. One traversal replaces a recursive query you would otherwise write by hand.
GET /v1/tenants/:t/graph/fin.transfers/bfs
?rel=to_account&from=acct-flagged&depth=3keep it explainable
Keep the returned IDs and relationship information so an investigator can inspect the connection. Result shapes differ by graph operation; use a path-producing endpoint when you need the complete path.
Retail: people who bought this also bought
The classic two-hop recommendation, computed on live orders rather than a nightly export.
The relation
shop.lines (id PK, order_id, product_id, qty)
relation: "product_id" -> shop.productsTwo hops from a product
Product to the orders containing it, then out to the other products in those orders. Depth two, one call.
GET /v1/tenants/:t/graph/shop.lines/bfs
?rel=product_id&from=sku-8842&depth=2Then rank them by similarity
Traversal supplies candidate IDs. Your application can compare them with results from a separately prepared vector index. Use matching IDs and inspect the ranking. See vector setup.
POST /v1/tenants/:t/vector/shop.products/topkManufacturing: a supply-chain dependency
One supplier stops shipping. The question is what stops with it, several levels down.
The relation
mfg.bom (id PK, part_id, depends_on_part, qty)
relation: "depends_on_part" -> mfg.partsEverything downstream of a part
Blast radius is a traversal, and the depth is the answer to how far the problem travels.
GET /v1/tenants/:t/graph/mfg.bom/bfs
?rel=depends_on_part&from=part-4471&depth=5weights make it a route
Give the edge a cost - lead time, price, distance - and Dijkstra answers the cheapest path rather than the shortest hop count.
Enterprise: an org chart
Reporting lines connect each employee to a manager. Following those links answers questions about direct and indirect reports.
The relation
hr.people (id PK, name, manager_id, dept)
relation: "manager_id" -> hr.peopleEveryone under a manager
A self-referencing relation traverses the same way as any other.
GET /v1/tenants/:t/graph/hr.people/bfs
?rel=manager_id&from=p-17&depth=6What these have in common
-
The relation is the model. Declaring which column is an edge is the whole setup.
-
Maintain the relation. Declared relationships can be maintained with row writes; existing data may need a supported backfill.
-
Inspect the evidence. Read the returned IDs and links; choose the operation that provides the path details you need.
-
Start from zero — Declare a relation and traverse it.
-
All algorithms — The full set, with what each one costs.