The first question asked when building RAG is usually which vector database to use. For most organisations the answer is duller than expected.
01. pgvector Is Probably Enough
If you already run PostgreSQL, pgvector comfortably covers most enterprise scenarios and handles tens of millions of vectors without trouble. You keep your existing backup and permission arrangements and operate no extra system.
02. The Managed Option
If you don't want the operational load, managed services exist; setup and scaling aren't your job. In return the data sits outside and cost grows with volume.
03. Very Large Scale
If you need billions of vectors on your own infrastructure, you move to systems designed for that scale. Far fewer organisations fall into this band than assume they do.
04. The Search Engine Alternative
If you already have an enterprise search platform, most now support vector search too. Building on the existing investment without adding a component can be the lowest-friction route.
05. What Actually Decides Quality
The database choice isn't among the top three factors determining RAG quality. Chunking strategy, embedding model and search design matter far more. Spending weeks here is investing in the wrong place.
06. Keep It Replaceable
Abstract the search layer away from your application. Then changing the underlying store when volume grows or needs shift doesn't mean rewriting the application.