Side by side
| Vector database | Graph database | Relational database | Memory layer | |
|---|---|---|---|---|
| Answers | What text is similar to this? | How are these things connected? | What rows match these conditions? | What is currently true for this viewer, and why? |
| Unit | Embedding + payload | Node, edge | Row | Memory with validity and sources |
| Updates | Overwrite or add | Edit nodes/edges | Update rows | Supersede, keep history |
| Time | Metadata you add | Properties you add | Columns you add | Built in |
| Access control | Filters you apply | Your logic | Row-level policies | Viewer-scoped recall |
Vector vs graph
Vectors excel at fuzzy matching over text; graphs at explicit, multi-hop relationships. Graphs need schema and entity resolution; vectors need chunking and tuning.
Where relational databases fit
Your system of record — orders, accounts, invoices — belongs in a relational database. Memory ingests events from it; it doesn’t replace it.
RAG vs vector database
RAG is a pattern; a vector database is one component of it. RAG can also retrieve with keyword search, graph queries or memory recall.
Which to use for an agent
- Static documentation → vector or hybrid search.
- Explicit relationships you query directly → graph database.
- Transactions and records of truth → relational database.
- Facts about people and accounts that change over time, with evidence and scope → memory layer.
Frequently asked questions
Is a memory layer just a vector database with extra steps?
It often uses vector search internally, but adds extraction, reconciliation, time and access control.
Can I build it myself?
Yes; see the operations list on LangMem and Auld for what you would own.