---
title: "Vector database vs graph database vs memory"
description: "Vector, graph and relational databases answer what resembles a question, how records connect, and which rows match. None answers which fact is true now. A four-way comparison, with the case where memory is the right tool."
canonical: https://past.dev/vector-database-vs-memory
last-updated: 2026-08-26
---
# Vector database vs graph database vs memory

Source: https://past.dev/vector-database-vs-memory

A vector database answers what resembles my question. A graph database answers how these things are connected. A relational database answers which rows match these predicates. None of the three answers which fact is true today, because none of them stores when a fact started or stopped being true. A memory layer adds that: the same retrieval, plus a validity window on every fact, identity resolved across sources, and the dated evidence behind each claim. The four are not substitutes, and most production systems run at least two.

## The four side by side

Each column is a different question. Read the first row, decide which question you are actually asking, and the rest of the table follows from it.

|  | Vector database | Graph database | Relational database | Memory layer |
| --- | --- | --- | --- | --- |
| Question it answers | What is similar to this text? | How are these entities connected? | Which rows match these predicates? | What is true now, and what was true before? |
| Unit of storage | An embedding plus metadata | Nodes and edges | Rows in typed tables | Dated facts, each tied to the source that stated it |
| How you query it | Approximate nearest neighbour, with metadata filters | Traversal, in Cypher, Gremlin or SQL/PGQ | SQL | A natural-language question |
| What it does with time | A timestamp is one more metadata field to filter on | A property on a node or an edge | A column | The axis of the model: every fact carries when it held |
| What it does with identity | Whatever the writer put in the metadata | Nodes you merged yourself | A foreign key you maintain | Resolved at ingestion, and re-resolved as the graph grows |
| Two statements that disagree | Both chunks come back, ranked by similarity | Both edges exist | Both rows exist | The superseded value is kept as history, the current one is returned |
| Strongest at | Recall over a large unstructured corpus | Multi-hop questions over a schema you control | Exact, transactional, constrained lookups | Questions whose answer changed since it was written down |
| Needs a model at write time | An embedding model | No | No | Yes, extraction runs on ingest |

## Vector database vs graph database

A vector database stores embeddings and returns the nearest ones to a query embedding. It is the right structure when the corpus is unstructured, when you cannot predict the questions, and when good-enough recall beats exactness. It has no notion of a relationship: two chunks that mention the same person are near each other only if their wording happens to be near.

A graph database stores entities and typed relationships, and answers by walking them. It is the right structure when the question needs more than one hop, when relationships are the point rather than the text, and when you can define a schema in advance. The cost is that something has to build the graph: either you write structured data into it, or you run extraction over your text and accept that the extraction is now part of your correctness budget.

The practical rule: **if you can name the relationship in advance, a graph is cheaper to query and easier to trust. If you cannot, embeddings are cheaper to build and more forgiving.** Systems that need both usually run both, with the graph carrying identity and the vectors carrying passages.

## Knowledge graph vs vector database

A knowledge graph is a graph database with a commitment: the nodes are the things your domain is about, and the edges are typed facts rather than arbitrary links. That commitment is what makes it explainable. An answer is a path, and a path can be shown to a reader.

Against a vector database, the trade is precision for coverage. The graph knows only what was extracted into it, and a fact nobody modelled is a fact it cannot return. The vector index holds everything, and returns whatever is nearby, including the paragraph that was near for the wrong reason. [Knowledge graphs for LLM applications](/knowledge-graph-for-llm) goes into what a graph does well and what it leaves out.

## Vector database vs relational database

These two are the least alike, and the comparison is usually a proxy for a different question: do I need a new database at all? Often not. `pgvector` puts approximate nearest neighbour search inside Postgres, so vectors live in the same database, the same transaction and the same backup as the rows they belong to.

Keep the relational database for anything that has a schema, a constraint or an invoice attached to it. Reach for vectors when the input is prose and the query is a question rather than a predicate. The failure mode worth avoiding is inferring from text a fact that is already a column somewhere.

## RAG vs vector database

These are not two options. **RAG is a pattern, a vector database is a component.** Retrieval-augmented generation means fetching context at question time and putting it in the model's prompt. The fetch can be an approximate nearest neighbour search, a keyword search, a SQL query, an API call or all four.

So the question is never RAG or a vector database. It is which retriever the RAG pipeline should call, and [choosing a vector database for RAG](/vector-database-for-rag) is that question in full.

## What each one does better than a memory layer

The honest part of the comparison, because a page that answers every question with its own product is not a comparison.

- **A vector database is cheaper and more predictable to write to.** Ingestion is an embedding call and an insert, with no language model deciding what a document means, so cost per document is flat and the result is deterministic. A memory layer runs extraction at ingest, which costs more per document and is not deterministic.
- **A vector database gives you the knobs.** Your embedding model, your chunk size, your index parameters, your recall and latency curve. A managed memory API decides those for you.
- **A graph database is exact where extraction is approximate.** If your entities and relationships already exist as clean records, put them in a graph and traverse them. There is nothing for an extractor to get wrong.
- **A relational database wins whenever the fact is already a column.** Transactions, constraints, joins and decades of tooling, none of which needs a model in the loop.
- **All three are cheaper for pure lookup.** If a question is answered by one document that never changes, retrieval is the whole job and everything above retrieval is overhead.

## When memory is the right answer

Three conditions, together. The answer to the question changes over time, the input is unstructured text arriving continuously, and the same subject appears under different names in different sources. That combination is where similarity search quietly fails: both the old statement and the new one match the question, and the ranking has no reason to prefer the recent one.

The classic shape of the failure is a value that moved. Two emails, five months apart, about the same pilot:

```bash
curl -X POST https://api.past.dev/api/v1/ingest \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -d '{ "content": "Budget for the Acme pilot is 32k.",
        "timestamp": "2026-02-03T09:00:00Z" }'

curl -X POST https://api.past.dev/api/v1/ingest \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -d '{ "content": "Budget for the Acme pilot moved to 40k.",
        "timestamp": "2026-07-28T16:00:00Z" }'

curl -X POST https://api.past.dev/api/v1/answer \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -d '{ "query": "what is the Acme pilot budget?" }'
```

A similarity search over those two documents returns both, in whatever order the embeddings put them, and leaves the model to guess which one holds. past.dev returns the current value, the date it changed and the source that changed it, and keeps the previous value in the history rather than deleting it.

```json
{
  "answer": "40k. It moved from 32k on July 28.",
  "evidence": [ { "marker": 1,
      "label": "Email from Nadia, 2026-07-28" } ],
  "abstained": false,
  "usage": { "answerCostUsd": 0.000431,
             "recallCostUsd": 0.000214 }
}
```

> **Not a replacement**
>
> past.dev does not remove the need for a vector database over your own documents, and it is not a store for structured records. It answers questions about history that changed. Keep the rest where it is.

## How to decide in one pass

1. Is the fact already a column in a database you own? Query it. Stop.
2. Is the corpus static documents, and does the answer stay put once written? A vector database and a retrieval pipeline are enough.
3. Do the questions need two or three hops over entities you can model? A graph, built from records where you have them.
4. Does the answer change, in prose, across sources that name the same subject differently? That is what a memory layer is for.
5. Most systems answer yes to more than one. Run more than one.

## Frequently asked questions

### Is a vector database enough for agent memory?

It is enough for recall, and recall is only part of memory. A vector index will find the passages that resemble the question. It will not tell you which of two contradicting passages holds now, will not merge the same person across sources, and will not decline to answer when the evidence is thin. Those are the parts that have to be built on top, either by you or by a memory layer.

### What is the difference between a knowledge graph and a vector database?

A knowledge graph stores typed entities and explicit relationships and answers by traversal, so an answer is a path you can show. A vector database stores embeddings and answers by similarity, so an answer is a ranked list of passages. Graphs are precise about what was modelled; vectors cover everything but justify nothing.

### What is the difference between RAG and a vector database?

RAG is a pattern: fetch context at question time and put it in the prompt. A vector database is one possible retriever inside it. A RAG pipeline can equally retrieve with keyword search, SQL or an API call, and many production pipelines use several at once.

### Can I use a vector database and a memory layer together?

Yes, and it is the common shape. Keep documents you own in your vector index, and use memory for the timestamped history where the answer moves. `POST /api/v1/recall` returns ranked evidence with sources and no generated text, so the result can be merged with your own retriever before it reaches the model.

### Do I still need Postgres?

Almost certainly. Application data, billing and anything with a constraint belongs in a relational database. `pgvector` also puts vector search inside the same Postgres, which is why it is the cheapest first step for most teams rather than a dedicated vector service.

## Related

- [Choosing a vector database for RAG](https://past.dev/vector-database-for-rag)
- [Knowledge graphs for LLM applications](https://past.dev/knowledge-graph-for-llm)
- [What is agent memory?](https://past.dev/what-is-agent-memory)
- [Memory API overview](https://past.dev/docs/memory-api/overview)
- [How we measure memory](https://past.dev/benchmarks)