---
title: "Vector database vs graph database vs memory"
description: "Compare vector, graph and relational databases with a temporal memory layer by query type, storage model, identity handling and support for changing facts."
canonical: https://past.dev/vector-database-vs-memory
last-updated: 2026-10-09
---
# Vector database vs graph database vs memory

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

A vector database retrieves similar records. A graph database traverses relationships. A relational database returns rows matching predicates. A temporal memory layer resolves entities and records validity periods, sources and previous values for facts extracted from text. Applications often combine two or more of these systems.

## The four side by side

Choose the storage model based on the query and data requirements shown below.

|  | 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 | Each fact includes a validity period |
| 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 | Current and historical questions over changing facts |
| 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 records to a query embedding. Use it for unstructured corpora and open-ended similarity queries. It does not store explicit relationships. Two passages about the same person may receive unrelated scores if their wording differs.

A graph database stores entities and typed relationships. Use it for multi-hop queries over a defined schema. Applications can write structured records directly or extract entities and relationships from text. Model-based extraction adds cost and can introduce errors that must be measured.

Use a graph when relationships are known and typed. Use embeddings when questions are open-ended and the source data is prose. Systems can use the graph for entities and relationships and vectors for source passages.

## Knowledge graph vs vector database

A knowledge graph represents domain entities as nodes and typed facts as edges. The application can show the nodes and edges used for a result.

A graph can return only facts represented as nodes and edges. A vector index retains every embedded passage but can return text that is related without containing the answer. [Knowledge graphs for LLM applications](/knowledge-graph-for-llm) covers these tradeoffs.

## Vector database vs relational database

`pgvector` adds approximate nearest-neighbour search to Postgres. Vectors can share the database, transactions and backups used by application rows.

Use a relational database for structured data with schemas, constraints, and transactional requirements. Use vectors for similarity queries over prose. Query structured fields directly instead of extracting the same facts from text.

## RAG vs vector database

RAG is a pattern. A vector database is one possible retrieval component. A RAG pipeline can retrieve context with nearest-neighbour search, keyword search, SQL queries, API calls or a combination.

Select retrievers based on the data and query requirements. See [choosing a vector database for RAG](/vector-database-for-rag).

## What each one does better than a memory layer

These databases are better choices than a memory system for several common workloads.

- **A vector database has predictable write cost.** Ingestion requires an embedding call and an insert. The result is deterministic for a fixed embedding model. A memory layer runs model-based extraction during ingestion, which adds variable cost and output.
- **A vector database exposes search configuration.** Teams choose the embedding model, chunk size, index parameters and recall-latency tradeoff. A managed memory API controls these settings.
- **A graph database supports exact traversal over structured records.** Existing entities and relationships can be written directly without extraction from text.
- **A relational database is appropriate when the fact is already a column.** It provides transactions, constraints and joins without model-based extraction.
- **All three cost less for simple lookup.** A static document or structured row does not require fact extraction and temporal update handling.

## When to use temporal memory

A temporal memory layer is useful when facts change over time, unstructured text arrives continuously and the same subject appears under different names. Similarity search can retrieve both previous and current statements without identifying their validity.

The following example records two values for the same pilot budget five months apart.

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

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

curl -X POST https://api.past.dev/api/v1/recall \
  -H "Authorization: Bearer $PAST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "query": "what is the Acme pilot budget?",
        "identity": "demo-user" }'
```

A similarity search over those two documents returns both in embedding order and leaves the model to determine which one is current. The past.dev response instead returns ranked documents with occurrence dates and source excerpts, which gives the application the material needed to apply its own answer policy.

```json
{
  "asOf": "2026-07-29T00:00:00Z",
  "usedEvidenceTokens": 18,
  "results": [
    {
      "id": "39d9d745-c9f4-4884-a602-e538def76815",
      "rank": 1,
      "occurredAt": "2026-07-28T16:00:00Z",
      "content": "Acme pilot budget: currently 40k.",
      "artifact": {
        "id": "9f74f854-d11d-4bc4-bf68-5b2012ac9c15",
        "kind": "claim",
        "occurredAt": "2026-07-28T16:00:00Z"
      },
      "sources": [
        {
          "sourceId": "call-8821",
          "occurredAt": "2026-07-28T16:00:00Z",
          "excerpts": [
            "Budget for the Acme pilot moved to 40k."
          ]
        }
      ]
    }
  ]
}
```

> **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.

## Selection checklist

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 retrieval, which is one part of memory. A vector index finds passages that resemble the question. It does not identify which conflicting passage is current, resolve one person across sources or report insufficient evidence. You must add those capabilities or use a memory system that provides them.

### 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. The application can show the traversal path. A vector database stores embeddings and returns a ranked list of similar passages. Graphs cover modeled relationships, while vector indexes cover embedded source passages.

### 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. Keep static documents in a vector index and use temporal memory for timestamped history in which facts change. `POST /api/v1/recall` returns ranked evidence with sources and no generated text, so the application can merge it with other retrieval results before the model call.

### 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

- [How to choose a memory system](https://past.dev/guides/choose-memory-system)
- [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)