What Is a Knowledge Graph and How Does It Differ From a Vector Database?

A knowledge graph is a way of representing information as a network of real-world entities — people, places, concepts, events — connected by explicit relationships, so that both what a piece of data is and how it relates to everything else are captured together, rather than the relationships being left implicit or reconstructed later. Concretely, a knowledge graph is built from nodes (the entities), edges (the relationships connecting them), and labels (what those entities and relationships actually mean) — and it’s that explicit structure of connections, not just a store of facts, that separates a knowledge graph from an ordinary database or document store.

Where the Term Comes From

The term “knowledge graph” entered mainstream use after Google announced its own Knowledge Graph in 2012, built specifically to improve search results by understanding entities and their relationships rather than just matching keywords — when you search for a person and see a structured summary panel with their occupation, birthplace, and related people alongside the usual list of links, that’s a knowledge graph surfacing structured, connected facts rather than just ranking documents. That release is largely responsible for popularizing the term, even though the underlying idea of representing knowledge as connected entities predates it.

How Knowledge Graphs Actually Get Built

There isn’t one single way a knowledge graph comes into existence — in practice it’s usually one of three approaches, or some mix of them:

• Manually, by domain experts who define entities and relationships directly, which produces high accuracy but doesn’t scale well to large or fast-changing domains.
• Extracted automatically from unstructured or semi-structured data, using natural language processing (increasingly, an LLM) to identify entities and the relationships between them from raw text — contracts, articles, documentation — and turn that into graph structure without a human hand-authoring every node and edge.
• Assembled from existing knowledge graphs or structured sources, merging and reconciling multiple existing sources of structured knowledge into one, typically with some validation step to catch conflicts or duplicates introduced by combining sources that don’t perfectly agree.

Most production systems today lean heavily on the second approach, since manually authoring a graph over any large, real-world dataset simply doesn’t scale, and using an LLM to extract entities and relationships from text has become practical enough to make automated construction the default starting point.

Knowledge Graph vs. Knowledge Base: Not Actually Rivals

These two terms get used almost interchangeably, but they describe different things, and the relationship between them is one of containment rather than competition. A knowledge base is any structured, centralized repository of information meant to be looked up — FAQs, documentation, policy manuals — organized so it’s easy for a person (or a search system) to find and read. A knowledge graph is a specific way of organizing that information, one built explicitly around entities and the relationships between them rather than around documents or articles.

Practically, this means every knowledge graph functions as a kind of knowledge base — it stores retrievable knowledge — but not every knowledge base is a knowledge graph, since plenty of knowledge bases are just organized collections of documents with no explicit relationship structure connecting them. The difference shows up directly in what you get back from a query: a knowledge base typically returns whole articles or documents that seem relevant, while a knowledge graph can return a precise, assembled answer built from traversing specific relationships between entities, or the connections themselves as the actual result.

Knowledge Graph vs. Vector Database: Different Questions, Not Competing Answers

This comparison comes up constantly, and it’s worth being precise about what each one is actually optimized for, because they’re not solving the same problem. A vector database stores data alongside its embeddings and finds items that are semantically similar to a query — it’s built to answer “what else is like this,” working well over unstructured, loosely connected data at scale, with comparatively low setup and maintenance overhead. A graph database (the infrastructure a knowledge graph typically runs on) stores entities and their explicit relationships, and is built to answer a structurally different question: “what is this connected to, and through what path,” which is exactly the kind of multi-hop reasoning — this person works at that company, which was founded by that other person, who also serves on this board — that similarity search alone has no native way to express.

Vector search finds things by proximity of meaning; graph traversal finds things by explicit, followable connection. A vector database has no concept of “walk from this entity to that one through a specific relationship type” — it only knows how close two things are in embedding space. A knowledge graph, conversely, has no built-in notion of “these two entities are semantically similar even though nothing directly connects them” — that’s precisely the gap embeddings are good at filling. Choosing between them isn’t about which is more advanced; it’s about which question your application actually needs answered, and for a large share of real applications, the honest answer is both.

GraphRAG: Combining Both Instead of Choosing One

This is exactly the reasoning behind GraphRAG, an umbrella term for retrieval-augmented generation approaches that use a knowledge graph as part of the retrieval step, rather than relying purely on vector similarity search. The general pattern looks like this: source documents are processed by an LLM to extract entities and the relationships between them, building a knowledge graph as a byproduct of ingestion; closely related entities can then be grouped into “communities” using graph-clustering algorithms, with an LLM generating a summary for each community that captures what that cluster of entities is collectively about.

At query time, a hybrid retrieval pipeline can use vector search to find the entities most semantically relevant to a user’s question, then use those entities as starting points to traverse the graph — pulling in directly connected entities, relevant community summaries, and the specific relationships between them — assembling a much richer, relationship-aware context than semantic similarity over isolated documents could produce on its own. This is particularly valuable for data that’s genuinely rich in interdependencies — contracts between multiple parties, research citation networks, organizational records — where the connections between entities carry real information that plain vector search over independent document chunks would simply never surface, since each entry is treated as an isolated vector with no encoded relationship to any other.

What This Looks Like in Practice

A concrete version of this pipeline: extract named entities (people, organizations, locations) and their relationships from a batch of documents using an LLM, store those entities in a vector database so they’re findable by semantic similarity to a query, and store the graph structure itself — the relationships between entities — in a graph database designed for relationship traversal. A user’s question gets embedded and matched against the vector store to find the most relevant entry points into the graph; from those entry points, the graph database traverses outward along relevant relationships to assemble the connected context an LLM needs to actually answer a question that spans multiple related facts rather than one isolated one.

Temporal Knowledge Graphs: When Relationships Change Over Time

A more recent evolution worth knowing about is the temporal knowledge graph, which extends the same entity-and-relationship model with an explicit notion of time: relationships aren’t just true or false, they’re true during a specific period, and can be superseded by new facts without simply overwriting the old ones. This matters specifically for applications like long-running agent memory, where a fact learned last month (“the user works at Company A”) might genuinely become outdated (“the user now works at Company B”) — a temporal knowledge graph can represent both facts along with when each was true, rather than forcing a choice between silently overwriting history or letting two contradictory facts coexist with no way to tell which one is current.

When You Actually Need a Knowledge Graph

A knowledge graph earns its complexity specifically when the relationships between your data points carry information that similarity alone can’t capture — multi-hop reasoning across connected entities, a need for explainable, traceable answers (showing exactly which facts and connections produced a result, rather than a similarity score), or data that’s inherently relational in nature, like organizational structures, supply chains, or citation networks. For simpler retrieval needs — finding documents similar in meaning to a query, without a strong dependency on the specific relationships between them — a vector database alone is usually the simpler, cheaper, and entirely sufficient choice. The two aren’t in competition so much as they’re answers to genuinely different questions, and knowing which question your application is actually asking is most of the decision.