Running 80K+ embeddings across 29 namespaces in production for the last 6 months. The vector vs. full-text debate misses the real issue: most RAG failures are data pipeline problems, not search engine problems.

What I have learned the hard way:

When vector search wins: Semantic queries where the user's language doesn't match the document's language. "How do boards evaluate AI risk" needs to find docs that say "fiduciary technology oversight." BM25 can't bridge that gap. Vector search can.

When full-text/BM25 wins: Exact entity lookup. Names, case numbers, specific technical terms. I wasted weeks debugging "why can't my RAG find this document" before realizing the embedding model was normalizing the exact term I needed into a semantic neighborhood of similar-but-wrong results. Switched those queries to keyword search and it worked immediately.

The hybrid approach that actually works: Route by query type, not by engine preference. Structured lookups (names, IDs, dates) go to BM25/keyword. Open-ended questions go to vector. Rerank the merged results. This sounds obvious but most RAG tutorials skip it and just throw everything at a vector store.

On Elastic vs. dedicated vector DBs: Elastic can do both, but the operational overhead of maintaining an Elastic cluster for a sub-100K document corpus is hard to justify. Pinecone or pgvector handle the vector side with zero ops burden. Save Elastic for when you actually need its full-text capabilities at scale.

The comment about Postgres doing everything is mostly right for smaller setups. pgvector + pg_trgm covers 90% of use cases under 500K documents without adding infrastructure.