Over the first half of 2026, three things happened that, taken together, unsettled a default architecture most teams had stopped questioning: embed everything, put it in a vector database, do a similarity search, done. Anthropic's Boris Cherny confirmed that Claude Code deliberately doesn't use vector search for codebase retrieval — the team tried it and dropped it. Qdrant raised a $50 million Series B built partly around rejecting the idea that vector databases are commodity infrastructure. And a study from PricewaterhouseCoopers researchers, published as a preprint, found that under specific conditions, a 50-year-old command-line tool can outperform dense vector search. None of these three things say what the loudest summaries of them say. That gap is the useful part.
What Is Happening?
The immediate spark was Cherny's account, given in an interview with Gergely Orosz's The Pragmatic Engineer, of how Claude Code's retrieval was built. Anthropic tried "local vector databases, recursive model-based indexing, and other fancy approaches" for searching a codebase, and dropped all of them. The reasons were concrete: vector indexes go stale as code changes, and they introduce permission complexity in shared repositories that a live grep query doesn't have. What replaced it was simpler than what it replaced — plain grep and glob, driven by the model deciding what to search for and when. Cursor, Windsurf, and Devin have reportedly converged on broadly similar approaches for coding agents.
That finding, specific to codebases, has since been generalized into a much broader claim circulating across blog posts and social feeds: agents don't need vector search, full stop. Vendors who sell vector search infrastructure disagree, and they have their own evidence. Qdrant's CEO points out that agentic workloads issue "hundreds or even thousands of queries per second" against a document corpus — a volume and latency profile that looks nothing like the one-question, one-answer pattern retrieval-augmented generation (RAG) was originally built around. GlassDollar, a Qdrant customer, migrated off Elasticsearch at 10 million documents and reported a 40% infrastructure cost reduction and triple the engagement. &AI runs a patent-litigation agent across hundreds of millions of documents, built specifically around retrieval as what its founder calls "the core primitive, not generation," to reduce hallucination.
Both stories are true. They're describing different workloads.
Why It Matters
If an engineering team takes "Claude Code doesn't use vector search" as a general architectural rule and applies it to, say, a customer-support assistant retrieving from years of unstructured ticket history, they're applying a finding from one workload (bounded, lexically dense source code) to a completely different one (large, semantically varied natural-language documents). The reverse mistake is just as common: standing up a dedicated vector database for a retrieval problem that a Postgres instance with the pgvector extension would have handled at a fraction of the operational cost.
The actual engineering question was never "vector search or not." It's a workload-fit question: how big is the corpus, how fast is it growing, what does the query pattern look like, and how much operational overhead can the team absorb for the difference in retrieval quality. Most of the public debate skips straight past that question to a verdict.
Understanding the Technology
Three distinct approaches get discussed as if they were two, or one:
Vector similarity search — via a dedicated engine (Qdrant, Milvus, Pinecone, Weaviate) or via pgvector inside PostgreSQL — embeds documents into high-dimensional vectors and retrieves nearest neighbours by distance. This is what most people mean by "RAG" as it's been built since 2023.
Lexical, agent-driven search — grep, glob, ripgrep, with the model deciding what to search for in real time — has no pre-built index. It never goes stale, and it doesn't require a second datastore to keep in sync with the source of truth.
Hybrid, multi-signal retrieval — combining vector similarity with keyword search, metadata filters, graph traversal, or temporal filtering in a single query — is what Elastic pitches as its retrieval stack, what a pgvector and full-text-search combination inside Postgres approximates, and what research systems like Vectorize.io's Hindsight implement for agent memory specifically, using four parallel retrieval modes rather than vector search alone.
Most production disagreements aren't actually about which of these three is "correct" — they're about which one fits a specific corpus size, query pattern, and freshness requirement.
What the Industry Is Learning
Demonstrated, not just claimed: pgvector with HNSW indexing can match or beat a purpose-built engine at the 1-million-vector scale on suitable hardware — this is Supabase's own published benchmark, not a marketing claim, and it complicates any simple "pgvector is always slower" narrative. Separately, one independent benchmark report — whose full methodology wasn't published, so the specific figures are worth treating as illustrative rather than definitive — put pgvector at roughly 18ms p50 latency against Qdrant's 4ms at that same 1-million-vector scale. Both results can be true at once; the gap widens or narrows depending on index configuration and hardware, and most sources agree pgvector remains workable up to somewhere between 10 million and 50 million vectors before a dedicated engine's advantage becomes clear.
Emerging, not yet settled: the PwC study is the most rigorous piece of evidence in this debate, and it's more nuanced than how it's being summarized. The researchers tested grep against vector retrieval across four agent harnesses and five models on 116 questions from the LongMemEval benchmark. With results delivered inline — dumped straight into the model's context — grep beat vector search on every harness-model pair tested. But with results delivered programmatically, through a file the agent has to explicitly open and read, vector search won on half the configurations tested. In one case, the same grep retrieval scored 93.1% accuracy delivered inline and 55.2% delivered via file — a nearly 38-point swing from changing how results reach the model, not from changing what found them. The authors are explicit that they "do not claim that grep 'beats' vector in general," only that it can win under the specific task distribution they studied. That caveat rarely survives the summarizing.
Open debate: whether Elastic's and Qdrant's public positioning — both, unsurprisingly, arguing their own approach is essential — reflects a genuine technical consensus or competitive messaging from vendors defending a revenue line neither of them wants to concede is commoditized. Both are true simultaneously; that doesn't make either company wrong about the workloads their own customers report, but it's worth naming rather than treating vendor commentary as neutral analysis.
Our Engineering Perspective
We build retrieval-augmented systems and AI chatbots for enterprise clients across Malaysia and the wider region, so this debate isn't abstract for us — it maps directly onto decisions we'd be asked to make on a client's behalf. Our view is that neither side of the "grep vs. vector search" argument is the right starting question. The right starting question is what the workload actually looks like.
For a retrieval problem that's bounded and structurally regular — searching a codebase, an internal API reference, a well-organized document set that changes often — a lexical, agent-driven approach removes real operational cost: no second datastore, no sync pipeline, no stale index to notice and fix. For a retrieval problem over a large, semantically varied corpus that an agent is going to query repeatedly and autonomously — enterprise document search, multi-turn support assistants, long-running research agents — the evidence points the other way. Retrieval quality at that scale generally benefits from more sophistication, not less, whether that's a dedicated vector engine or a hybrid retrieval layer.
Where we'd push back hardest against the current framing is the assumption that a dedicated vector database is the default starting point for a mid-size deployment. Many of the RAG systems we'd realistically be asked to build for a client — a retail chain's product knowledge base, a manufacturing plant's equipment documentation, a mid-size financial services firm's policy corpus — would likely sit well under the scale where pgvector inside an existing Postgres-backed stack is a defensible choice, not a compromise. It also avoids introducing a second system that needs its own monitoring, backup strategy, and access control model. The signal to watch for isn't a fixed vector count; it's whether query patterns start looking write-heavy and high-frequency in a way that a human-facing RAG system never would — that's the shift Qdrant's customers describe, and it's a genuine architectural trigger, not a vanity metric.
The PwC finding on delivery mechanism is the part of this research we'd want any client considering a "just use grep" pattern to see before they adopt it. It's tempting to treat Claude Code's architecture as a template. The underlying lesson generalizes less cleanly than the summary suggests — the same retrieval method produced wildly different results depending on a detail (how results are handed to the model) that has nothing to do with retrieval quality itself. Anyone borrowing a pattern from a coding-agent harness should check whether their own harness matches the conditions the pattern was actually tested under.
Practical Considerations
Architecture: Decide based on corpus size, growth rate, and query pattern before picking a retrieval mechanism — not the reverse. A second datastore is a standing maintenance cost, not a one-time setup cost.
Cost: pgvector inside an existing Postgres instance avoids the infrastructure and licensing cost of a second system for workloads under roughly 10 million vectors. Beyond that range, most sources agree the latency and throughput advantages of a dedicated engine start to justify the added operational overhead — though the exact crossover point varies by benchmark and hardware, so validate against your own corpus rather than a published number.
Reliability: Lexical retrieval doesn't go stale the way a vector index can, but it has no notion of semantic similarity — a query that doesn't share vocabulary with the target content will miss it entirely. Test retrieval quality against real user queries, not just queries phrased the way your documents are written.
Scalability: The PwC study's delivery-mechanism finding is a scalability trap worth testing for directly: benchmark any grep-based or file-based retrieval pattern under the exact tool-delivery configuration your agent harness actually uses, not a generic benchmark's configuration.
Governance: None of the sources reviewed here address data governance or compliance implications directly — that's a gap in the current public discussion, not a settled answer, and worth raising explicitly with any client evaluating a retrieval architecture change for regulated data.
Should Engineers Adopt It?
Experiment, and specifically: experiment against your own workload rather than adopting either "grep replaces RAG" or "you need a vector database" as a general rule.
The evidence doesn't support a single verdict, and it shouldn't — the sources that disagree most sharply are, on close reading, describing different corpus sizes and query patterns, not contradicting each other. What would change this recommendation: a benchmark result on a corpus and query pattern genuinely comparable to yours, run under your own harness's actual delivery mechanism. Nothing in the current evidence base substitutes for that specific test.
Conclusion
The retrieval architecture debate produced two of the most widely repeated, most oversimplified data points in AI engineering this year — Claude Code dropping vector search, and a study showing grep beating it. Both are real findings. Neither is a general rule, and the study itself says so explicitly. The practical lesson isn't which retrieval method wins; it's that a result reported under one set of conditions — a specific corpus, a specific harness, a specific way of handing results back to the model — doesn't travel to a different set of conditions just because the headline is easier to remember than the caveat.
Working with Mandrill Tech
If your team is building or evaluating a RAG-based system for enterprise use, Mandrill Tech's Generative AI & AI Chatbots practice works through exactly this kind of architecture decision — sizing the corpus, choosing the retrieval layer, and validating quality against your actual query patterns, not a generic benchmark. With over 10 years of enterprise delivery across 200+ projects in Malaysia and the region, we design retrieval systems that hold up in production. Talk to Mandrill Tech about the right retrieval architecture for your workload.
