A hands-on enterprise RAG (Retrieval-Augmented Generation, hooking a knowledge base up to an LLM) post on Juejin drops a striking number: 90% of teams building an AI knowledge base get the first step wrong—architects green-light a distributed dedicated vector database (Milvus, Pinecone, etc.), bolt on managed cloud hosting and ops, and the system breaks on day one across accuracy, operations, and the bill. The post's verdict is blunt: at or below the 10-million-document threshold, enterprises don't need to buy a separate vector database at all. A single PostgreSQL setup with pgvector (the vector search extension) and BM25 (the classic keyword matching algorithm) running hybrid retrieval returns high-precision results in 30 milliseconds.
What This Is
Building an enterprise AI knowledge base is, at its core, about getting AI to "look something up before it answers" across internal documents, product manuals, and support tickets. Sounds simple—but the retrieval layer is where things most often go wrong.
Over the past year, the fashionable approach has been "pure vector retrieval": convert each passage into an array of numbers (an embedding), then find answers by numerical similarity. This method is great at "understanding meaning"—search "car broke down" and it can find "engine failure." But throw it a string that demands exact matching—a product SKU like GTX-4090-D, a person's name like Zhang Weimin, an error code like Err-502—and it falls apart: either it surfaces a pile of look-alike nonsense, or it misses the right answer entirely.
The fix is called "hybrid retrieval": one lane does semantic recall via embeddings, the other does exact recall via BM25, then the two result sets are merged and re-ranked. PostgreSQL, the venerable relational database, already does full-text search out of the box. Add the pgvector extension and it stores vectors too. One database handles both jobs, eliminating the dual-write consistency headaches of running a "vector database + relational database" pair.
Industry View
Supporters say the post punctures enterprise IT's "tool worship": too many architects treat "deploying a distributed vector database" as a badge of technical sophistication, even though most enterprises (data volumes in the tens of millions or below) will never approach that scale. This "slaughtering a chicken with a cow-sized knife" approach drives up the bill, adds operational burden, and creates data consistency problems.
But the counterargument stands on its own merits: this approach has a hard ceiling—at the 10-million scale it works, push past that and a single PostgreSQL instance buckles, at which point a distributed vector database becomes genuinely necessary. At the same time, "hybrid retrieval" sounds nicer than it is—it demands a team that can tune embeddings, configure Chinese tokenization for BM25 (which means wiring up jieba), and implement Reciprocal Rank Fusion (RRF), the algorithm that merges and scores the two retrieval lanes by rank. For IT teams in traditional industries, that bar is not low. Put differently, you don't erase the technical debt—you shift it from infrastructure to model and algorithm tuning.
Impact on Regular People
For enterprise IT: when a vendor pitches a dedicated vector database, ask one thing—"what's our actual data volume?" Below 10 million, PostgreSQL + pgvector + BM25 deserves a serious look. What you save isn't just money—it's operational complexity and compliance overhead.
For working professionals: terms like RAG, vector retrieval, and hybrid retrieval are migrating out of the algorithm engineer's vocabulary and into the working vocabulary of product managers, operations staff, and IT managers. You don't need to understand the implementation, but the next time you sit down with an IT colleague on an AI project, you should at least be able to ask: "are we using pure vector retrieval or hybrid?"
For consumer markets: the next time you hit an AI customer support bot or try to look up a product manual, expect fewer complaints about "the model number won't match" and "the error code won't search"—provided enterprise IT gets the retrieval layer right.