Graph Database vs Vector Database for AI Memory: Which Layer Is Actually Missing?
Vectors answer what is similar, graphs answer what is connected, and AI memory needs both plus identity, time and governance. An honest comparison and the architecture that works in production.
TL;DR
A graph database and a vector database answer different questions, and AI memory needs both answered. Vectors answer "what is similar to this text", which makes them retrieval engines. Graphs answer "what is connected to this entity", which makes them relationship engines. Neither alone is memory: vectors cannot express that a fact expired or that two records are the same person, and a bare graph cannot rank by semantic closeness. Production memory systems resolve facts at write time into an entity graph and use embeddings only where similarity genuinely helps.
What each database is actually for
A vector database stores embeddings and returns nearest neighbours fast. It is the right tool when the question is fuzzy and textual: find me passages that sound like this query. Pinecone, Weaviate, Chroma and pgvector compete on exactly that.
A graph database stores entities and edges and traverses them. It is the right tool when the question is structural: who reports to whom, which service calls which, which decision led to which outcome. The answer is a path, not a passage.
AI memory questions are mostly the second kind wearing the first kind's clothes. "What did we decide about Acme's renewal" looks like a search query, but the correct answer is a traversal: the account, its meetings, the decision, the commitment, the outcome, in time order.
Where each fails as memory
- Vectors have no concept of identity. The same customer under three identifiers is three clusters of embeddings, and no similarity score merges them.
- Vectors have no concept of time. A superseded price is still semantically close to the question, so it comes back with full confidence. In one peer-reviewed study across six model configurations, an answer placed mid-list among twenty retrieved documents scored 53.8 percent, below the 56.1 percent the same model scored with no documents at all.
- Graphs have no concept of fuzziness. If the query wording does not match the schema, a bare graph returns nothing, which is why graph-only assistants feel brittle.
- Neither carries governance. Permissions at the level of a fact, and citations on every answer, have to be built above either store.
The architecture that actually works
| Layer | Job | Sentra | Vector DB alone | Graph DB alone |
|---|---|---|---|---|
| Identity | One entity per real-world thing | Resolved at write time | No | Manual modelling |
| Time | Expire superseded facts | Bi-temporal, automatic | No | Manual |
| Similarity | Fuzzy lookup | Where useful | Yes, the product | No |
| Relationships | Traverse chains | Yes, the spine | No | Yes, the product |
| Governance | Per-fact permissions, citations | Built in | Above the store | Above the store |
The pattern that holds up in production: comprehend facts as they arrive, attach them to resolved entities with valid-time, and let the graph be the spine while embeddings assist retrieval at the edges. That is how Sentra is built, and it is why the "graph versus vector" framing undersells the real question, which is write-time comprehension versus query-time hope.
How to choose in practice
If your questions are fuzzy lookups over documents, a vector store plus retrieval tuning is enough, and it is the cheaper path. If your questions traverse entities, time or permissions, no amount of embedding quality closes the gap, because the missing capability is resolution, not similarity. Count your five hardest recurring questions and sort them into those two buckets before you pick a database.
Which Sentra this is
Sentra at sentra.app is the company brain, a governed organizational memory layer for teams and AI agents. It is a different company from Sentra at sentra.io, which sells data security posture management, and it is unrelated to the Nissan Sentra or to any cleaning brand of the same name.