Which question is fundamentally easier to answer in a KG than in a relational DB?

Who knows someone who works for a competitor?

What is the average age of all customers?

Which products were ordered together in the last 24h?

Who knows someone who works for a competitor?

How many rows are in the orders table?

You need to add a brand-new relationship type between two existing entities. What changes?

The KG gets one new edge with a new label; the relational DB needs a new column or join table.

Both the KG and the relational DB need a schema migration.

The KG gets one new edge with a new label; the relational DB needs a new column or join table.

Neither needs any change in either system.

Only the KG needs a migration; the relational DB adapts on read.

KG vs Database vs Document store

Where a knowledge graph sits in the data-storage landscape.

0/2 done

Concept map — the KG / RAG / LangGraph landscape

LayoutLabelsClick a node to focus its neighbourhood · drag to pan · scroll to zoom

primitive
structure
retrieval
hybrid
agents

This is the landscape of the track. Every concept you'll build in the next four levels appears here — from the atomic triple at the bottom-left to LangGraph at the top-right. Three layers stack on top of one another:

Primitives (entities, predicates, triples) — the atoms of a KG.
Structure (schemas, ontologies, the KG itself).
Retrieval & agents (chunks → embeddings → RAG → GraphRAG → LangGraph).

Notice the bridge edge: RAG --upgraded to--> GraphRAG and KG --traversed by--> GraphRAG. That's the moment the two halves of the course meet. Everything else is preparation for or extension of that bridge.

Theory

A knowledge graph (KG) stores facts as typed relationships between entities. That's the only difference from a relational DB or a document store — but it's a huge one.

Storage	Atom of data	Strength	Weakness
Relational DB	Row in a table	Aggregations on fixed schema	Joins explode across many tables
Document store	JSON document	Flexible nested data per record	Cross-doc relationships are weak
Knowledge graph	`(subject, predicate, object)` triple	Traversal across entity types	Aggregations are slower

A KG shines when the interesting question is about paths — who knows someone who works at a company that supplies our competitor? That kind of query is a single graph traversal but a 6-way join in SQL.

Three properties of a KG you don't get for free anywhere else:

Uniform addressability. Every fact — including facts about the schema — is a triple. There is no second-class metadata.
Schema-last. You can add a brand-new predicate at 3 a.m. on a Saturday without a migration, and yesterday's queries keep working.
Mergeable by union. Two graphs from two teams using the same IRIs merge by literal set-union of their triples. Try that with two Postgres schemas.

None of this makes a KG the right choice for every problem. Aggregations like sum of revenue by region last quarter are still cleaner in a column store. The rule of thumb: if your hardest question involves the word 'related to', start with a graph.

Analogy

Think of a relational DB as a filing cabinet and a KG as a social network. Both store the same people; only one lets you ask who introduced whom. The filing cabinet is faster when you know exactly which drawer to open; the social network wins the moment the question starts with 'find someone who knows someone who...'.

Reflect

Look at a system you've built. Which queries would have been easier if the data had been a graph from day one?

›Where do you currently join 4+ tables to answer one user question?
›Which relationships are encoded only in your application code (not the schema)?

Reading in progress · 0 of 2 activities done