KG vs Database vs Document store

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:

1. Primitives (entities, predicates, triples) — the atoms of a KG.
2. Structure (schemas, ontologies, the KG itself).
3. 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.

A knowledge graph is a data model that represents facts as typed, named relationships between entities. Its atomic unit is the triple (subject, predicate, object) — and these triples collectively form a directed, labeled graph. Unlike relational databases or document stores, the schema is not fixed; new predicate types can be added without migration, and the graph can be queried by traversing paths.

A KG shines when queries involve indirection: “Find suppliers whose CEOs previously worked for our competitors” is a few hops in a graph, but a combinatorial join in SQL.

Four unique properties of KGs (not all available in any single other system):

• Uniform addressability: every fact, including meta‑facts about the schema, is a triple — no “second‑class” data.
• Schema‑last evolution: new relationship types can be added at runtime without breaking existing queries.
• Mergeability: two KGs with same IRIs merge by set union (schema and instance triples alike).
• Reasoning support: explicit semantics (e.g. subClassOf, domain/range) enable inference of new triples.

The rule of thumb: if your hardest questions involve connections or chains of relationships, a KG is likely the right fit — but it’s not a replacement for column‑stores when you need billion‑row aggregates.

Think of a relational DB as a spreadsheet of facts — you know which rows to look up, and aggregations are fast. A KG is more like a social network — you care about who knows whom, and who works with whom, and you often ask “find someone who is connected to X through no more than three steps”. The spreadsheet wins when you need “sum of all sales”; the social network wins when you need “people who are friends of friends”.