Which workload screams 'use a graph DB'?

Find every account within 4 hops of a known fraudster

Which question is the *worst* fit for a graph database?

'Sum revenue by region for last quarter, broken down by product category'

'Who shares a device or address with any account flagged in the last 90 days, up to 3 hops?'

'Sum revenue by region for last quarter, broken down by product category'

'Shortest supply-chain path from supplier S to factory F'

'Find clusters of users with overlapping follows'

When the Right Model is a Graph — Semantic Web Academy

Overview

When the Right Model is a Graph

If your hardest queries are 'who is connected to whom, how, through what?', stop joining and start traversing.

Why it matters

Graph modelling (Neo4j, RDF) wins for recursive / variable-depth questions — fraud rings, knowledge bases, recommendations, supply chain. See the Neo4j and Semantic Web tracks.

Going deeper

Graph-shaped problems share a fingerprint:

Variable-depth traversal — 'within N hops', 'shortest path', 'reachable set'. SQL needs recursion; Cypher writes ()-[*..N]-().
Pattern matching — 'A introduced B who introduced C, all within 30 days'. Reads like a sentence in a graph language.
Heterogeneous relationships — user, device, address, payment all linked by many edge types. A relational equivalent is a forest of junction tables.
Inference / reasoning — 'if X is a parent of Y and Y is a parent of Z, then X is an ancestor of Z'. Semantic-web stacks (RDF + OWL) do this natively.

Counter-fingerprint (= not a graph problem): bulk aggregations over tabular facts, high-throughput key lookups, document storage. Reaching for a graph DB on those workloads buys you complexity without payoff.

Analogy

Graphs are how detectives think, relational tables are how accountants think.

An accountant wants rows that balance: customers, orders, line items in neat ledgers. A detective wants the web: who called whom, who introduced whom, who shows up at the same café as the suspect three times this month. The detective doesn't care about row counts — they care about paths.

In SQL, the detective's question becomes 7 self-joins and a recursive CTE; the query plan looks like origami and the execution time grows with hop depth. In a graph DB, the same question is one Cypher / SPARQL traversal that just walks the relationships the schema already encoded.

Make it stick

Use the prompts below to anchor when the right model is a graph to something you actually own.

›Pick a SQL query in your codebase with 4+ joins or a recursive CTE. Could it become a 5-line graph traversal?
›Which 'fraud / risk / recommendation / lineage' use case in your org would benefit most from a graph model — and what's blocking the migration?
›Where would adding *graph thinking* on top of your relational schema (e.g. a property-graph projection in Neo4j) be cheaper than re-platforming?

Reading in progress · 0 of 2 activities done