THE RAG QUESTION
Memory is just RAG with a new name.
Published Updated
If you have built with retrieval before, this one feels obvious. You embed the past conversations, you do a similarity search, you put the top results in the prompt. That is memory, is it not. People say it plainly, that AI memory is just a rebrand of persistence, and that vector embeddings are not some special class of data that deserves its own product.
The fair version of this is strong, so let us give it its due. Retrieval over past chats really is a big part of the job, and vector search is a solved, cheap primitive. If retrieval were the whole problem, a vector store would be the whole answer.
It is not the whole problem. RAG retrieves documents. Memory maintains a model of the user and the world over time. The difference is not where the data sits, it is the set of operations on top of it. A vector store returns the nearest chunks and stops. It does not write back, it does not reconcile two facts that contradict each other, it does not know that "John from Acme" and "John Smith" are the same person, it does not decay a preference the user changed three weeks ago, and it does not rank by anything richer than cosine similarity. Similarity is not relevance. The closest chunk is often not the one that should change the next action.
We do not have to argue this from theory. We ran the experiment. Across five domains, from Python code to scientific papers, we ingested 50,000 documents and fired 5,000 queries at them, expecting vector search to win comfortably. It did not. Real-time embedding generation turned out to be a tax, and the "semantic dream" of embed-everything did not match the engineering reality once the data got messy and the volume got real.
So here is the reframe. RAG is a component inside a memory system, not a substitute for one. AI Memory is a data pipeline and fast-search problem, not a storage problem alone, and getting the pipeline right, the writing, the resolution, the temporal sensitivity, the conscious forgetting, is iterative depth work that a vector store does not do for you.
Synap is that pipeline. We score 92% on LongMemEval and 93.2% on LoCoMo, not because our vector search is magic, but because retrieval is only the last step of something larger.
How do vector databases compare for AI memory use cases?
They compare on four axes that matter and one that does not. What matters: write-path latency under concurrent load, filtering quality when you scope by tenant and user, operational burden, and whether the store can express time so that a newer fact beats an older one. What matters less than vendor pages suggest is raw nearest-neighbour recall, which is close to a solved problem across the field.
The proof, in numbers
Questions people ask before deciding
If you already run Postgres, start with pgvector, because the operational saving usually outweighs the performance gap until you are well past a million vectors. Pinecone and Qdrant reduce the operational burden further at a cost. Weaviate and Milvus suit teams that want hybrid search in one system. Redis fits when the same store also holds session state.
You need one when relationships between entities carry meaning that similarity cannot express, which is the case for multi-hop questions such as who introduced two people and when. Neo4j and FalkorDB are the names that come up. The cost is a second system to operate, so most products do not need it on day one and some never do.
They share a retrieval step and diverge everywhere else. RAG retrieves from a corpus that you control and that does not argue with itself. Memory retrieves from a history that accumulates, contradicts itself, and has to be revised and sometimes deleted. Same index, entirely different write path.
Cost is driven by the number of vectors held hot, the embedding dimension, and replication, rather than by query volume in most deployments. The figure that surprises teams is re-embedding: a model change forces a full re-index, and that is a line nobody budgets for on the way in.
Yes, for longer than most teams expect. pgvector with an HNSW index handles a large share of production memory workloads, and you keep transactional consistency between the memory and the rest of your data, which a separate vector store cannot give you.
Read the file-vs-vector experiment, then try Synap.