)
Last updated: October 22, 2026
What is the difference between a knowledge graph, a context graph and a vector database? A knowledge graph stores facts as things and the links between them. A vector database stores text as numbers so it can find passages that mean something similar. A context graph records how decisions were made, so people and agents can reuse precedent. Most AI memory needs more than one of them.
TL;DR: Key Takeaways
- Google's Knowledge Graph launched in May 2012 with more than 500 million objects and more than 3.5 billion facts about how they connect.
- A knowledge graph is built from triples (subject, predicate, object), the unit defined in the W3C's RDF 1.1 Concepts, a Recommendation dated February 25, 2014.
- A vector database finds text by meaning, but Microsoft Research (2024) reports that graph-based indexing gave more comprehensive answers than conventional retrieval on broad questions over corpora of about 1 million tokens.
- "Context graph" is a young term: Foundation Capital's Ashu Garg (December 26, 2025) describes it as decision traces linked across accounts, tickets, policies, approvers and time.
- In PoisonedRAG (USENIX Security 2025), five malicious texts per target question, planted in a knowledge base of millions of texts, reached a 90% attack success rate.
- OWASP lists vector and embedding weaknesses as LLM08 in its 2025 Top 10 for LLM applications.
At a Glance: The Three Structures Side by Side
The three structures answer different questions. A knowledge graph answers "how are these things connected?", a vector database answers "what text sounds like this?", and a context graph answers "why was this done?". The table sets them next to each other in plain terms before the sections below go deeper into each one.
| Knowledge graph | Context graph | Vector database | |
|---|---|---|---|
| Question it answers | How are these things connected? | Why was this decided, and what precedent applies? | What text sounds like this? |
| What it stores | Entities and labeled links between them | Decision traces linked across people, policies and time | Embeddings: lists of numbers for chunks of text |
| Best at | Precise answers that follow links | Reusable precedent and an audit trail | Fast, fuzzy search over messy text |
| Weak spot | Needs extraction and upkeep | Young term, no formal standard, needs decisions captured | Finds similar passages, not relationships |
| Everyday analogy | A map of people, projects and who owns what | A case file of why the team chose A over B | A librarian who finds pages that feel relevant |
| Common building blocks | RDF triples, property graph databases such as Neo4j | Emerging, no common standard | Embedding models plus approximate nearest neighbor indexes such as HNSW |
How we compared
We compared the three on what each stores, the question it answers best, how it is built and where it fails. Definitions come from primary sources: Google's 2012 announcement, the W3C's RDF specification, the Hogan et al. survey, the original RAG and HNSW papers, Microsoft's GraphRAG paper and Foundation Capital's essay on context graphs. The team example later in the article is invented for illustration.
What Is a Knowledge Graph?
A knowledge graph stores information as a network of things and the relationships between them. Each fact is one small link, such as "Priya owns the Acme renewal", and thousands of links form a map you can query. Google brought the idea to a wide audience in 2012, and companies now build private versions for their own data.
Facts as triples and labeled links
The simplest form is the triple. According to the W3C (2014), an RDF triple has a subject, a predicate and an object, and an RDF graph is a set of such triples. "Priya", "owns", "Acme renewal" is one triple. Add "Acme renewal", "depends on", "SSO support" and the two facts now connect through the item they share.
A second style is the property graph. According to Neo4j's documentation, nodes represent entities. Relationships link a source node to a target node, with a direction and exactly one type. Both can hold key-value properties. In practice you can store the date a note was written on the link itself. Both styles describe the same idea: things, links, and details about each.
Where you already meet knowledge graphs
According to Google (2012), its Knowledge Graph held more than 500 million objects and more than 3.5 billion facts and relationships at launch. That let Search answer questions about specific people, places and things instead of only matching keywords. The survey by Hogan and colleagues (2021) covers both open knowledge graphs and the private ones companies build around their own data. A customer map and a product catalog that links parts to suppliers are knowledge graphs in spirit, even when nobody calls them that.
How a knowledge graph gets built
Building one follows the same few steps, whether a person or a program does the work:
- Decide which things matter: people, projects, customers, decisions, files.
- Pull those things and their links out of the source material, by hand, by rules or with a language model.
- Merge duplicates, so "Priya", "Priya S." and "P. Shah" become one node.
- Store the nodes and links in a graph database.
- Query the graph with a graph query language, or let a model turn a plain question into one.
The Hogan et al. survey covers each stage, from graph data models and query languages to creating, enriching and refining the graph. The language-model route is shown in Microsoft Research's GraphRAG paper (2024). A model extracts a graph of entities and relationships from documents. The graph is then grouped into clusters of closely related entities, and the model pre-writes a summary for each cluster.
Benefits and limits of a knowledge graph
The main benefit is that answers can follow links. "Who owns the SOC 2 audit, and what is blocked until it finishes?" is a two-hop question, and a graph walks both hops without guessing. The path it followed also doubles as an explanation you can show a colleague.
The limits are practical. Someone has to define what counts as a thing, extraction makes mistakes, duplicates creep in, and facts go stale unless something updates them. A knowledge graph is also poor at "find me the paragraph that feels like this", because feelings do not live in links.
)
What Is a Vector Database?
A vector database stores text as embeddings, long lists of numbers placed so that similar meanings sit close together, and returns the closest matches to a question. It is the engine behind most retrieval-augmented generation (RAG), where a system fetches a few relevant passages and hands them to the model before it answers.
How a vector search works
The recipe is short. Split your notes into chunks, run each chunk through an embedding model and store the numbers. When a question arrives, turn it into numbers the same way and fetch the nearest chunks. Comparing against every chunk gets slow at scale, so most systems use approximate nearest neighbor search.
According to Malkov and Yashunin (2016), one well-known method, HNSW, stacks several graph layers over the data. A search starts on a sparse top layer and descends, which gives logarithmic scaling. The index inside many vector databases is itself a graph, but a graph of points in space, not a graph of facts about the world.
Why vector search became the default
Lewis and colleagues (2020) paired a text-generating model with an external index of Wikipedia passages stored as dense vectors and searched by a neural retriever. That is the pattern RAG systems still follow. Knowledge sits outside the model's weights and is fetched on demand. That is why a vector database is usually the first thing a team adds when it wants an assistant to answer from its own documents.
Where a vector database falls short
Vector search returns passages that sound similar. It does not know that two passages are about the same person, that one decision replaced another, or who approved what. According to Microsoft Research (2024), conventional RAG works for narrow, fact-finding questions but fails on broad questions about a whole corpus, such as its main themes.
Time is another gap. An old note and a newer one can look equally relevant to a similarity search.
What Is a Context Graph?
A context graph is a newer idea: a graph that records how decisions were made, including exceptions, approvals and precedents, so people and agents can see why something was allowed. The term comes from industry writing rather than a formal standard, so expect definitions to keep moving.
Decision traces, in plain words
According to Foundation Capital's Ashu Garg (2025), decision traces are records of how a specific case was handled. They include the exception granted, the override, the approval, the precedent cited and how a general rule was applied. Most companies do not store this reasoning. It lives in chat threads, calls and people's memory.
A context graph is the structure that forms when many decision traces are linked across accounts, tickets, policies, approvers and time. That makes precedent searchable. For example: "the last time a customer asked for a longer trial, who agreed and why?"
What a context graph is not
Garg's essay is explicit that the graph explains why an action was permitted, not what happened inside a model's head. In our reading it is also not a replacement for a knowledge graph. A knowledge graph can hold the entities, such as customers, policies and people, and decision traces add the choices that connect them over time.
Treat it as a design pattern more than a product category. Unlike RDF, which has a W3C Recommendation, context graphs have no formal specification that we know of. The essay is also an investor's argument, so weigh it as a perspective, not a measurement.
When a context graph is worth the effort
It pays off when decisions repeat and someone later asks "why did we do that?": discounts, exceptions, approvals, incident calls. For a personal pile of notes you will probably never need one. The cost is capture. A decision is hard to reconstruct afterwards, so the trace has to be written down when the decision happens.
One Example, Three Ways: A Week of Team Meetings
Take a five-person team that spent a week on three customer calls, a shared notes folder and a busy chat channel. A vector database finds the paragraph that mentions the renewal. A knowledge graph shows who owns it and what it depends on. A context graph shows why the discount was approved. Same material, three different questions.
| Question you ask | Best structure | What comes back |
|---|---|---|
| What did we say about SSO this month? | Vector database | Matching passages from notes and chats |
| Who owns the SOC 2 audit, and what depends on it? | Knowledge graph | A person, a project and the items linked to it |
| Why did we give Acme a longer trial? | Context graph | The approval, the exception and the precedent behind it |
| What are the main themes across this quarter's calls? | Knowledge graph with cluster summaries | Summaries per group of related entities, the GraphRAG approach |
| What did we decide about pricing? | A mix of all three | Candidate passages, the people involved and the recorded decision, with sources |
The second and third rows are where plain similarity runs out. A pile of text does not say that the person in the call notes is the owner in the project plan. That connection is exactly what a graph stores.
Seen as a picture, the graph is also the part you can look at. You get dots for people, projects and decisions, lines between them, and clusters where related things bunch together, such as sales notes next to support threads. A similarity index is invisible by comparison, which is one reason graphs make good teaching diagrams.
Knowledge Graph vs Context Graph vs Vector Database: How to Tell Them Apart
The quickest test is the question you need answered. If it is "find me something like this", use vector search. If it is "how is this connected to that", use a knowledge graph. If it is "why did we decide this", you need decision traces, which a context graph organizes. Real projects often need two or all three.
Querying, cost and upkeep
| Knowledge graph | Context graph | Vector database | |
|---|---|---|---|
| How you ask | Graph queries that follow links, or a plain question turned into one | Follow a chain of decisions, approvers and policies | A plain question turned into numbers and matched |
| Explainability | High: you can show the path of links | High if traces are captured: shows approvals and precedent | Lower: shows similar passages and a closeness score |
| Upfront work | Define entities, extract them, merge duplicates | Capture decisions as they happen and link them to entities | Split text into chunks, choose an embedding model |
| Handling change | Update or replace the affected facts | Append new traces so precedent accumulates | Re-embed the text that changed |
| Typical failure | Missed or duplicated entities from extraction | Gaps where no decision was recorded | A similar-sounding but wrong passage |
Where the lines blur
The labels overlap more than the definitions suggest. HNSW, the index inside many vector databases, is a graph. GraphRAG uses a knowledge graph built from text to improve what vector-style retrieval can answer. A context graph sits on top of the same entities a knowledge graph holds. Vendors also use the three terms loosely. A better question than "which label is this?" is "what is stored, and what question does it answer?"
Why AI Memory Usually Mixes All Three
An assistant that remembers your work needs fuzzy recall and precise structure at once. Vectors find the right paragraph among thousands of notes, a knowledge graph ties people, projects and files together, and decision traces keep the reasons. That reasoning sits behind approaches such as GraphRAG, and it is why a memory for AI usually needs more than one structure.
GraphRAG: the best-documented hybrid
According to Microsoft Research (2024), GraphRAG works in two indexing stages. First a language model extracts a knowledge graph of entities and relationships from the source documents. Then the graph is grouped into clusters and the model writes a summary for each. To answer a question, the system drafts a partial answer from each cluster summary and combines them.
On broad questions over corpora of about 1 million tokens, the authors report more comprehensive and more diverse answers than a conventional RAG baseline. These are the authors' own results on their own test sets, so treat them as promising evidence, not a universal ranking.
What this means for a second brain
TrustBrain, the AI memory product NeuralTrust is launching, shows a person's or a team's memories as a graph you can look at, with clusters where related items group together. This article does not describe its internals. It is about the structures, because any memory product has to decide which of them to use.
Whatever product you try, a few questions cut through the labels:
- Can you see the sources behind an answer, or only the answer?
- Can you see and export what the memory holds, so you can leave?
- Who else can read it, and how is that decided?
- What happens when two notes disagree?
Security and Governance: Risks of Graph and Vector Memory for AI Agents
Memory makes an agent more useful and gives attackers something lasting to target. OWASP's 2025 Top 10 for LLM applications lists vector and embedding weaknesses as LLM08, covering access control gaps, cross-context leaks and poisoned content. The risk exists in graphs and vector stores alike.
| Risk | How it shows up | Applies to | Control to start with |
|---|---|---|---|
| Unauthorized access and data leakage | Weak access controls let someone retrieve personal or sensitive data from the memory | Graph and vector | Permission-aware access, with datasets separated logically (OWASP LLM08) |
| Cross-context leaks | In shared setups, one group's data surfaces in another group's queries | Graph and vector | Separate datasets per group and tag data with access levels |
| Memory poisoning | A planted text changes future answers: in PoisonedRAG, five malicious texts per target question reached a 90% attack success rate | Graph and vector | Validate sources, track where data came from, audit for hidden content |
| Embedding inversion | Attackers may reconstruct much of the original text from stored embeddings | Vector | Protect embeddings like the text they came from |
| Links that cross permissions | A link can connect a public item to a restricted one, so access rules must follow the links (our design view) | Graph and context graph | Check permissions on every hop of a query |
| No audit trail | Nobody can tell who read or wrote what | Graph and vector | Detailed, tamper-resistant logs of retrieval (OWASP LLM08) |
The poisoning numbers deserve a second look. According to the PoisonedRAG authors (USENIX Security 2025), injecting five malicious texts per target question into a knowledge base of millions of texts achieved a 90% attack success rate. The knowledge base was huge and the attacker's input was tiny, which is the part to remember when a memory accepts content from chat, email or the web.
Context graphs help in one specific way. Decision traces carry provenance: who approved what, and when. OWASP's mitigation list for vector weaknesses includes validating knowledge sources and tracking where data came from, which lines up with the idea behind decision traces.
NeuralTrust's own explainer, What is Memory & Context Poisoning? (Alessandro Pignati, January 7, 2026), describes how attackers corrupt an agent's long-term knowledge. Targets include RAG indexes and vector stores, and the agent keeps making flawed decisions long after the attack. The post recommends context isolation, provenance tracking and memory auditing. NeuralTrust, a Barcelona-based AI agent security company, builds Agent Runtime Security (TrustGuard) and an Agent Gateway (TrustGate). Both work at runtime, on what agents send and call, and they are separate from whichever memory design you choose.
Which Should You Choose?
Choose by the question you ask most often, not by the label that sounds most advanced. Start with the simplest structure that answers it, then add the next one when you hit a question it cannot handle. Access rules come first in every case, because retrofitting permissions onto a memory that already holds everyone's data is painful.
| Your situation | Start with | Why |
|---|---|---|
| A small pile of personal notes and chats | Vector search | Similarity search answers most everyday questions with little setup |
| You need to know who owns what and what depends on it | Knowledge graph | Links answer ownership and dependency questions directly |
| Agents or teams make repeated judgment calls you must justify | Context graph | Decision traces keep the reasons and the precedent |
| Shared team memory across meetings, documents and chat | A mix, plus visible sources | Vectors find passages, graphs connect them, sources let you check |
| Several teams or customers share one store | Any of them, with permission-aware access first | OWASP flags cross-context leaks in shared setups |
Conclusion
A knowledge graph maps things and their links, a vector database finds text that means something similar, and a context graph keeps the reasons behind decisions. None replaces the others. For a few notes, vector search is enough. For a team, expect to need links and decisions too, plus access rules from day one. Pick by the question you need answered, not by the label.
Building Shared Memory for Your Team? Let's Talk
NeuralTrust is launching an AI memory product for people and teams who want to own what their AI knows. If you are weighing graphs, vectors or both, book a demo and tell us what you want your agents to remember.
Related Reading
FAQs about knowledge graph
1. What is a knowledge graph in simple terms?
A knowledge graph is a map of things and how they relate. Each fact is a small link, such as "Priya owns the Acme renewal". Thousands of links let software answer questions by following connections instead of matching words. Google's version, launched in 2012, held more than 500 million objects and more than 3.5 billion facts at launch.
2. What is the difference between a knowledge graph and a vector database?
A knowledge graph stores explicit facts and links, so it can answer "who owns this and what depends on it". A vector database stores text as embeddings and finds passages that mean something similar. The first is precise and explainable but takes work to build. The second is quick to set up but does not know how things relate.
3. What is a context graph?
A context graph is a newer term for a graph of decision traces: the exceptions, approvals and precedents behind choices, linked across accounts, tickets, policies, approvers and time. Foundation Capital's Ashu Garg described it in December 2025. There is no formal standard for it yet, so definitions vary between writers and vendors.
4. Do I need a knowledge graph for RAG?
No. Basic RAG works with a vector database alone, and it handles narrow, fact-finding questions well. A knowledge graph helps when questions are broad or depend on relationships. Microsoft Research's GraphRAG paper reports better comprehensiveness on broad questions over corpora of about 1 million tokens, using a graph extracted from the documents.
5. Can a vector database and a knowledge graph work together?
Yes, and many AI memory designs combine them. The vector side finds candidate passages by meaning, and the graph side connects the people, projects and decisions those passages mention. GraphRAG is the best-documented example: a language model extracts a graph from documents, clusters it, and answers from cluster summaries.
6. What are the security risks of graph and vector memory?
The main ones are data leakage through weak access controls, cross-context leaks in shared stores, poisoned content, and embedding inversion. OWASP lists vector and embedding weaknesses as LLM08 in its 2025 Top 10. In PoisonedRAG, five malicious texts per target question reached a 90% attack success rate against a knowledge base of millions of texts.
About the Author
Roger Howroyd is Head of Global SEO and AI at NeuralTrust, where he leads the company's search strategy across SEO, AEO, GEO, and LLM optimization. He specializes in AI-powered search, content strategy, and SEM. Connect on LinkedIn.
NeuralTrust is the leading platform for securing and scaling AI agents. Named a Pioneer in the Gartner Emerging Market Quadrant for AI Application Security 2026, recognized across four Gartner Hype Cycle reports in 2026, and featured in the Gartner Market Guide for Guardian Agents 2026, the Gartner Market Guide for AI Gateways 2025 and the KuppingerCole Leadership Compass for Generative AI Defense 2025. Headquartered in Barcelona with offices in London and New York. ISO 27001 certified.
Sources
- Google, Introducing the Knowledge Graph: things, not strings (May 16, 2012)
- W3C, RDF 1.1 Concepts and Abstract Syntax (Recommendation, February 25, 2014)
- A. Hogan et al., Knowledge Graphs (arXiv:2003.02320, v6, September 2021)
- Neo4j, Graph database concepts (documentation, checked October 22, 2026)
- Y. Malkov and D. Yashunin, paper introducing Hierarchical Navigable Small World (HNSW) graphs (arXiv:1603.09320, 2016)
- P. Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (arXiv:2005.11401, May 22, 2020)
- D. Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft Research, arXiv:2404.16130, v2, February 19, 2025)
- A. Garg, AI's trillion-dollar opportunity: Context graphs (Foundation Capital perspective, December 26, 2025)
- OWASP GenAI Security Project, LLM08:2025 Vector and Embedding Weaknesses (2025)
- PoisonedRAG: Knowledge Corruption Attacks to Retrieval-Augmented Generation of Large Language Models (USENIX Security Symposium, August 2025)
)
)
)
)