“We don’t store your documents, we store vectors” is usually false
· Prabhu Eshwarla
A sentence that sounds like a privacy guarantee, is usually a misunderstanding, and can be checked in about two minutes.
The sentence
Somewhere in most AI product conversations, someone asks what happens to the documents. And a version of this comes back:
We don't store your documents. We convert them into vectors, a list of numbers, for search.
It is reassuring. It sounds like the content has been through a one way door and come out the other side as mathematics. Nobody is lying when they say it. But in nearly every retrieval system it is false, and the reason is worth understanding, because it changes what you should ask for next.
What actually happens when you upload a document
A retrieval system does roughly four things with a file.
It extracts the text. It splits that text into chunks, usually a few hundred words each, because a whole document is too big to hand a model. It embeds each chunk, turning it into a list of numbers that captures roughly what the chunk is about. And it stores the chunks so they can be searched.
The embedding is what makes search work. When you ask a question, your question gets embedded too, and the system finds the chunks whose numbers sit closest to your question's numbers.
Here is the part that gets skipped: once the right chunk is found, the system needs the actual text back. It has to put that passage into the prompt so the model can answer from it, and it has to show it to you as a citation. An embedding cannot do either job, because an embedding cannot be turned back into the passage it came from. It is a summary of meaning, not a compressed copy.
So the text has to be kept. Not the original file, necessarily, but the text.
What that looks like in a database
This is the table Forge stores chunks in. It is unremarkable, and that is the point, because almost every retrieval product has one that looks like this:
create table document_chunks (
id uuid primary key,
document_id uuid not null,
chunk_index integer not null,
content text not null, -- the passage, as text
embedding vector(1024), -- the numbers, alongside it
metadata jsonb
);
Two columns. content holds your words. embedding holds the numbers. Both.
And because the chunks are stored in order, with an index, a full document can be reassembled from them. We have a function that does exactly that, because features like "show me this whole file" need it.
The honest summary of what a retrieval product holds is therefore: not your original file, but your text, in pieces, plus numbers that make the pieces findable.
Why the comforting version gets said anyway
Rarely dishonesty. Usually one of three things.
The engineer means the file. Many products genuinely delete the uploaded PDF after extraction. Ours does. That is a real and worthwhile practice, and "we don't store your documents" is a reasonable shorthand for it if everyone knows that is what is meant. The trouble is that the person asking heard something much stronger.
Embeddings sound irreversible, so people assume the text is gone. Embeddings are genuinely hard to invert. But irreversibility of the numbers says nothing about whether the text was kept, and in a retrieval system it was, because the product does not work otherwise.
Nobody asked the next question. "We store vectors" ends the conversation pleasantly. The follow up that matters is not "do you store vectors" but "what else is in that row".
The two minute check
You can settle this with any vendor, and you do not need to be technical.
Ask: "when your product shows me a citation, where does the quoted text come from?" If they can show you the passage, they have the passage. There is nowhere else it could be coming from.
Ask: "can your staff, with production access, read the text of a document I upload?" The honest answer for almost every retrieval product is yes, subject to access controls and logging. A vendor who says no should be able to explain exactly how, and the explanation should involve encryption keys they do not hold, not embeddings.
Ask: "what exactly is deleted when I delete a document?" You want to hear that the chunks go, and their embeddings with them.
None of these are gotchas. They are the questions that get you an accurate picture instead of a comfortable one.
What to want instead
Once you accept that the text is stored, the question stops being "is our content really there" and becomes the more useful set:
- Who can reach it. Per project or per document access, not per company.
- What was sent outside. Which passages left for a model call, and what was masked before they went.
- What is deleted, and when. Whether deletion reaches the derived data or only the original.
- Whether encryption means what you think. Encryption at rest protects against someone walking off with the storage layer. It is not a claim that the vendor cannot read your text, and a vendor who lets you believe it is has told you something false by omission.
Those are answerable, checkable, and they are what actually protects a document. "It's just numbers" protects nothing, because it was never the mechanism doing the protecting.
Our own answer, since it would be strange not to give it
Forge stores the text. It is in the content column above, in the table we use.
We do not keep your original file. After extraction it is deleted, because nothing reads it again. A file attached to a one off chat is never stored as a file at all, only its text, and that text goes when the conversation does. Personal data such as email addresses and phone numbers is masked before anything is sent to a model, by default.
But the text is there, and Forge can read it. Our security page says so in as many words, because the alternative is a sentence a reviewer can disprove in one query, and a vendor who is caught being comforting on the easy question does not get believed on the hard ones.
In one line. Almost no retrieval product turns your documents into numbers and throws the words away, because it needs the words back to answer you. Ask where the citation text comes from, and judge the vendor on access, masking and deletion rather than on a sentence about vectors.
