Why there is no vector database in it
Every few days someone who has built their own retrieval setup asks the same question about MindMax, and it is a good question: if there is no embedding pass over my folder, how does it find anything?
The short answer is that it finds material the way you would — by structure, by the words on the page, and by trying other wordings — and that documents small enough to read are read rather than retrieved from. The longer answer is that this is a trade with a real cost, and pretending otherwise would be the kind of claim that falls apart the first time someone tests it.
What we gave up
Say it plainly, because it is the part that usually gets buried in a footnote: a question phrased very differently from your files, or asked in a different language, can miss.
That is exactly what embeddings are good at. "It was about the moral hazard thing, I think" is a query with almost no lexical overlap with the paragraph you are looking for, and a vector index handles it gracefully. We do not, beyond generating a few alternative phrasings and trying those too. If most of your searching looks like that, a vector setup will serve you better, and you should use one.
What it buys
Four things, and they compound.
There is no wait before you can ask anything. Point at a folder and ask. Nobody has to sit through an indexing job on two hundred PDFs before the software becomes useful, which matters more than it sounds: the first five minutes decide whether people keep an app.
There is no stale index. Edit a note and the next question sees the edit. Anyone who has maintained a personal RAG pipeline knows the failure where the answer is confidently built on the version of a file from three weeks ago, and knows how long it takes to notice.
Exact terms stay exact. A statute number, a variable name, a citation string — precisely the things similarity blurs — are found literally, because looking for a specific sentence is a lookup and gets treated as one.
Cost stays proportional to what you actually read. Embedding everything means paying for everything, including the four hundred documents you will never ask about.
The part the argument usually skips
The interesting question is not "which retrieval method scores better". It is which failure is invisible.
A retrieval miss produces a fluent, well-sourced answer with the decisive paragraph missing, and there is no signal anywhere in the output that says so. You cannot audit what was not retrieved. The lexical miss, by contrast, is loud: you search, you get nothing useful, and you immediately know to try other words.
Given a choice between a failure mode you can see and one you cannot, on material you are going to make decisions from, we would rather have the visible one. That is a judgement about what personal document work is like, not a benchmark result, and it is fair to disagree with it.
Where this stops being about retrieval at all
Most of the advantage is not in the search at all — it is in not needing it. A twenty-page paper fits in a modern context window several times over, so chunking it solves a problem that does not exist. The whole text goes in, and the entire class of retrieval-miss failures never arises for that document. Books do not fit, so they get navigated by their own chapter structure and read section by section, the way a person uses a table of contents.
Retrieval is what happens at the edges: across a large folder, or inside a book too big to read whole. It is a fallback, and it is honest about being one.
One thing that is not true
It would be wrong to read any of this as "we do not have embeddings because they are bad". The vector layer exists in the codebase as an optional accelerator and is switched off in what we ship. If we turn it on later, nothing on this page stops being true — "you do not need to set one up" and "we could not" are different claims, and only the first one is ours.
Written up in more detail on full-text-first answering, with the practical version in how search works and the side-by-side comparison in MindMax vs. building your own RAG setup. If you want to try the behaviour rather than read about it, asking questions about your documents is the place to start.