Library · Data Practice OS

When a knowledge graph earns its place

Reference guide · Published · Source reviewed 2026-11-06

Short answer. A Knowledge graph earns its place when the relationships are the point of the question and those relationships go several hops deep, change often, or differ by type. For everything else, tables, a Semantic layer and search are cheaper and easier to govern. In the From data to decisions - the decision stack a graph is one technique for the meaning and knowledge layers. It is not the centre.

Status. Proposed practice. Not an agreed decision. Product names below are examples only, not recommendations. Verify capability, region and pricing before relying on any of them.

The test: is the question about relationships?

If the decision needs "rows filtered and summed", you do not need a graph. If it needs "follow the links until you find X", you might.

Question	Relationship-centric?	Better fit
How many licences expired last month?	No	Semantic layer metric
What does the current fee schedule say?	No	Effective-dated table
Which sections of which Acts and regulations does this provision depend on, and which were amended after 1 July?	Yes, multi-hop, typed links	Graph
Which vehicle models share a platform with the recalled one, across rebadges and model years?	Yes, lineage	Graph
If this bridge closes, which heavy-vehicle routes and permits are affected?	Yes, network	Graph, or network analysis on the asset tables
Which legacy programs, rules, models and tests connect to this table?	Yes, many-to-many, typed links	Two tables (nodes, edges) are usually enough (Tracing rules from legacy code to modern code)
Which customer records refer to the same person?	Partly	Entity resolution first. A graph can help explore it, but is not required

Three the organisation shapes that often pass the test:

Legislation cross-references. Provisions cite definitions, other provisions and instruments, each with commencement dates. "What else changes if this definition changes?" is a traversal.
Vehicle make and model lineage. Rebadges, shared platforms and renamed models mean recalls and statistics need the family tree, not one row.
Asset networks. Impact, connectivity and shortest-path questions over roads and structures are graph questions, whether or not a graph database answers them.

GraphRAG: what it buys and what it costs

GraphRAG builds a graph of entities and relationships from documents, usually with an LLM, then retrieves over that graph as well as over text chunks. The approach popularised by Microsoft Research (see the paper) also summarises communities of related entities so it can answer whole-corpus questions.

It helps with: questions that span many documents ("what themes recur across all incident reviews?"), questions that need multi-hop links that plain Vector search misses, and answers that must show how two facts connect.

It costs:

Indexing. Extracting entities and relationships calls an LLM over the whole corpus, and again when documents change. Budget it like any other pipeline and measure it (FinOps).
Authority. Relationships extracted by a model are proposals, not facts (Rule authority). A graph built this way needs a status on each edge and an owner who validates the edges that feed decisions.
Freshness. A rebuilt graph lags the source. For changing facts, query the system of record live.
Evaluation. You now evaluate extraction quality as well as answer quality (Evaluating AI systems).

Start with plain retrieval (RAG and enterprise search) and a curated evaluation set. Move to GraphRAG only when the evaluation shows multi-hop or whole-corpus questions failing.

The costs of any graph

Before adding a graph store, count:

A second permission model. Row and column policies in the warehouse do not follow data into a graph. You must replicate classification and access, and keep it in step, or the graph becomes a side door (Identity propagation).
Synchronisation. The graph is usually derived. Define it as a pipeline from governed data products, with lineage, not as a hand-maintained copy.
Modelling effort. A useful graph needs an Ontology or at least a clear schema of node and edge types (Ontology, vocabularies and entity resolution); the 6-node, 9-edge migration vocabulary in Tracing rules from legacy code to modern code is a worked example. This is the expensive part, and it is business work.
Skills and operations. Query languages, backups, upgrades and on-call for one more system.
Exit. Keep the source of truth in tables in open formats, so the graph can be rebuilt or replaced.

Options, as examples (verify)

Option	Shape	Note
Graph analytics on the existing platform	Run graph algorithms over warehouse tables without a separate store	Cheapest to govern. On Databricks, for example, GraphFrames (verify current support)
A graph engine beside the platform, reading governed tables	Algorithms in or next to the platform, results written back as tables	For example Neo4j Graph Analytics for Snowflake (verify availability in an Australian region)
A dedicated graph database	A separate store with its own query language and serving	For example Neo4j. Use when the graph is served to applications or agents at low latency

Prefer the first row until a real query proves it too slow. Write results that feed decisions back into governed tables, so the Decision record can cite them.

Not when

The question is filtering, aggregation or lookup. Use SQL and the semantic layer.
The relationships are few and stable. A join table is a graph that needs no new system.
Nobody owns the ontology. An unowned graph decays faster than an unowned table.
You cannot replicate access controls into it. Then it must not hold sensitive data.
It is being built because a design diagram has a graph in it. Start from a decision in the Decision inventory that needs one.

Source links: Data Practice reading list.