Vector memory
Text stored as vectors next to your rows, searched by meaning.
Without an OpenAI key text cannot be turned into vectors, and both writing and searching answer with an honest error. Paste one in OpenAI settings
Ask the warehouse a question — the closest records answer here.
Vector search — what it does differently
What you get. The passages closest in meaning to your question, each with a score. Not an answer — the raw material for one. Nothing is written for you.
Why that is. One phase. Text is split into chunks, each chunk becomes a vector, and a search compares your question's vector against them. Nothing is precomputed about how facts relate, so nothing has to be paid for in advance.
Where it wins. When the answer sits in one passage: prices, policies, product facts, “how do I connect X”. It is also the right home for data that keeps changing — a changed row costs one embedding call to re-index, while a graph would have to extract its relations again.
What it costs. Almost nothing. Ingest is one embedding call per chunk; a search is milliseconds against a real index, and its cost does not grow with the size of the store.
Where it is weak. It knows no relations. A question that needs forty documents makes something read all forty. And it never composes an answer — you, or an agent, must do that. An agent looping over this store can beat the graph on flexibility, because it can rephrase and search again; it pays per question instead of paying once at ingest.
The two do not share storage. Vectors live in the data service's SQLite, in the vectors table beside your rows. The graph lives in the RAG service's own folder. To have a document in both, upload it to both: you pay each one's ingest and get each one's kind of answer. Nothing is shared but the OpenAI key.