Your AI Agent Doesn't Need a Vector Database. Stop Building One.

Hey guys, Mr. Technology here.

I am going to say something the vector database industry does not want to hear. Most AI agents do not need a vector database. Most AI agents never needed one. The fact that your team spent six weeks evaluating Pinecone, Weaviate, and Qdrant, settled on a five-hundred-dollar-a-month deployment, indexed your twelve thousand documents, and is now debugging a hybrid-search problem you did not have — that is not engineering. That is a marketing-driven architectural mistake the agent ecosystem has been making for two years.

Your agent does not need semantic search. It needs retrieval that is fast, predictable, cheap, and explainable for the data you actually have. For the vast majority of teams shipping AI agents in 2026, that retrieval is full-text search. SQLite has had it for a decade. PostgreSQL has had it forever. Both beat embeddings on the workloads most agents are running, and I am done pretending otherwise.

The Math Nobody Wants To Do

Vector search wins when you have a lot of data, the data does not fit cleanly into keywords, and semantic similarity is what the user actually wants. That is a narrow band. Customer support transcripts. Multilingual corpora. Scientific abstracts. Code search across hundreds of millions of lines. Most agents are not doing any of them.

Most agents are doing one of three things:

One: retrieval over a small, structured corpus. A few hundred policy documents. A few thousand product SKUs. A few dozen internal runbooks. The whole corpus fits in fifty thousand tokens. The model can hold it in context. A vector database is not retrieval — it is a layer of indirection that costs you latency, money, and the ability to debug.

Two: retrieval over semi-structured operational data. Customer records. Ticket histories. CRM notes. These are not documents. They are rows. The right tool is a SQL query with filters and joins. A vector database on top of a SQL database is two systems you have to keep in sync, and the second one will lie to you the moment they drift.

Three: retrieval over knowledge the agent should already know. Company values. Coding style guides. Product tone. The right answer is a system prompt or a rules file, not a semantic search over a corpus the agent should never have to look up.

For none of these three cases do you need embeddings. For none of them does the cost-versus-benefit math work.

The FTS5 Argument

SQLite's FTS5 — and PostgreSQL's tsvector, and the OpenSearch / Meilisearch / Typesense family — give you ranked keyword retrieval with sub-millisecond latency on a single node, no GPU, no embedding model to host, no chunking pipeline to maintain, and no drift between what you indexed and what is in your source of truth. BM25 is not old. BM25 is the right baseline, and on most production agent corpora, BM25 with a stopword list beats a 1536-dimensional embedding for answer relevance. The BEIR team published this result over a year ago. The agent ecosystem ignored it because the venture money is in vectors, not in inverted indexes.

When you layer a cross-encoder reranker on top of BM25, you get retrieval that is as good or better than vector search on the workloads most agents run, at a tenth of the cost. It is the single highest-leverage retrieval primitive in modern agent design, and almost nobody uses it.

The Take

The vector database market in 2026 is a four-billion-dollar industry selling a solution to a problem most teams do not have. The reflex to add a vector database to an AI agent — before the agent is even working, before retrieval is even the bottleneck — is the reflex of a developer who has read too many Medium posts and not enough query plans. **The right first step for agent retrieval is tsvector or FTS5 with a stopword list, evaluated against your actual query log, instrumented with the latency and recall metrics that matter.** If BM25 with a reranker is not good enough, then you have a vector search problem. Most of you do not.

Stop building a vector database. Start building an agent.

— Mr. Technology