What Is a Knowledge Graph?

A knowledge graph is a way of storing information as a network of entities — people, places, products, concepts — connected by labeled relationships, rather than as rows in a table or fields in a document. Instead of asking “which rows match this filter,” a knowledge graph lets you ask “what is connected to this entity, and how,” and traverse those connections directly.

Nodes, edges, and why the shape matters

A knowledge graph is built from two things: nodes (entities, like Company, Person, or Product) and edges (relationships between them, like acquired, works_at, or depends_on). Each edge is typically labeled and directional — (Company A) -[acquired]-> (Company B) — and both nodes and edges can carry properties, similar to columns on a row.

The key difference from a relational model isn’t that relationships exist — foreign keys model relationships too — it’s that in a knowledge graph, the relationship is a first-class thing you can query directly, without joins. Finding everyone two hops away from a given person (“colleagues of colleagues”) in a relational database means writing a multi-way self-join; in a graph, it’s a traversal of two edges. As the number of hops grows, the join-based version gets slower and more awkward, while the graph traversal stays a straightforward walk. This is the same underlying tension that shows up when comparing graph data structures like BFS and DFS to array- or table-based representations — a knowledge graph is that structure applied to a persistent, queryable store of real-world facts rather than an in-memory algorithm problem.

Where knowledge graphs show up

Search engines use knowledge graphs to answer factual queries directly rather than just returning matching documents — recognizing that a query refers to a specific entity, then pulling connected facts about it. Enterprises build internal knowledge graphs to model relationships between products, customers, and organizational structure that don’t fit neatly into a single relational schema. Recommendation systems use them to find “products bought by people who also bought X” through graph traversal rather than precomputed correlation tables.

Knowledge graphs and LLMs

Knowledge graphs have become newly relevant alongside large language models, for a specific reason: an LLM’s knowledge is baked into its weights at training time, and it has no built-in way to verify a fact or trace where an answer came from. A knowledge graph gives a model something structured and explicit to query against.

This connects most directly to retrieval-augmented generation, which typically retrieves relevant text chunks from a vector database based on semantic similarity. A knowledge graph offers a different, complementary kind of retrieval: instead of “find text that’s similar to this query,” it’s “find entities and relationships that are structurally connected to this query.” Some systems combine both — vector search to find a relevant starting entity, graph traversal to pull in everything connected to it — because similarity search alone doesn’t capture the explicit, factual relationships between things that a graph encodes directly. This kind of structured retrieval also gives a model a defense against hallucination: an answer that cites a specific traversed path through known relationships is easier to verify than one generated purely from learned patterns. It’s also the kind of structured context source that fits naturally behind function calling or a Model Context Protocol server, where a model queries the graph as a tool rather than having the entire graph stuffed into its context window.

Knowledge graph vs. relational database

	Knowledge graph	Relational database
Core unit	Entities and labeled relationships	Rows and foreign keys
Multi-hop queries	Native traversal	Chained joins, cost grows with depth
Schema flexibility	Add new relationship types without migration	Schema changes often need migrations
Best at	”What’s connected to X, and how”	Aggregations, transactions, structured records
Query style	Graph traversal (e.g., Cypher, SPARQL)	SQL

Neither replaces the other in most systems. A relational database is usually still the right place for transactional records — orders, accounts, inventory counts — where ACID guarantees matter and the access pattern is mostly row lookups and aggregations, not deep traversal. A knowledge graph earns its place when the relationships themselves are the thing you need to query, not just the records at either end.

When it’s not worth the complexity

Modeling everything as a graph is tempting once you see how naturally it handles connected data, but it comes with real costs: a different query language to learn, different operational tooling, and a schema that’s implicit in the relationship types rather than enforced up front. If your queries are mostly “give me records matching these filters” with only shallow relationships, a relational or document store will usually be simpler to operate and reason about. Reach for a knowledge graph when the value is specifically in traversing multi-hop, evolving relationships — not just because the data happens to have some connections between entities.

The takeaway

A knowledge graph makes relationships between entities the primary thing you query, rather than something you reconstruct with joins after the fact. That shape is well suited to multi-hop questions, evolving relationship types, and — increasingly — giving LLMs a structured, verifiable source of facts to retrieve from alongside vector search. It’s not a replacement for relational databases so much as a different tool for a specific kind of question: not “which rows match,” but “what’s connected, and how.”