AI Answer Library
Short answer
Start from your data volume and the stack you already run, not from whichever database markets itself hardest. Below roughly a million vectors, and especially if your team already operates PostgreSQL, pgvector is usually the best answer — it adds no second system to keep alive. A distributed store such as Milvus earns its complexity above the ten-million mark, or when you need replication and online scaling. Qdrant occupies the middle ground when you need rich metadata filtering but no cluster. With no dedicated operations staff, take the managed option.
The table compares options for one scenario: an internal enterprise RAG knowledge base. It does not cover recommendation systems, image retrieval or other vector workloads. The scale column gives the range each option handles comfortably without extra architecture work — not a hard ceiling. Every tier can be pushed further at the cost of more tuning and more operations.
| Option | Deployment and operations | Comfortable scale | Who it fits |
|---|---|---|---|
| pgvector (PostgreSQL extension) | Lowest. If you already run PostgreSQL it is one extension; backup, permissions and monitoring are already in place | From tens of thousands up to about a million vectors on a single instance | Most internal knowledge bases, especially teams whose business data already lives in PostgreSQL |
| Qdrant | Low to medium. A single container gets you started; clustering is a separate step | One to ten million, with a clear edge when metadata filters get complex | Teams needing multi-condition filtering by department, date or document type without running a cluster |
| Milvus | High. Many distributed components, each needing its own monitoring, scaling and failure plan | Ten million and up, or wherever replication, online scaling and multi-tenancy are required | Organisations with a platform team, genuine scale, and retrieval shared across business lines |
| Managed vector service | Lowest for you — but data leaves your network and vendor lock-in must be assessed | Elastic; scale is largely not your problem | Teams with no operations staff, non-sensitive data, and a need to validate fast |
In practice, the ranked causes of poor retrieval are: bad chunking (context cut in half, or several topics crammed into one chunk), missing metadata filters (searching the entire corpus at once), an embedding model mismatched to the language or domain, no reranking stage — and only then differences in the vector store's own recall. Put differently: if your knowledge base answers badly today, swapping the vector database will most likely change nothing. A pragmatic order is to build the whole pipeline on the least burdensome option (usually pgvector), assemble an evaluation set, and let that evaluation set tell you which stage is actually holding you back.
A few signals are unambiguous. First, sustained growth past ten million vectors where index rebuild time now interferes with normal writes. Second, retrieval latency outside what the business tolerates, which neither index tuning nor more hardware brings back. Third, a need to scale retrieval independently, because transactional load and search load are now degrading each other on one instance. Fourth, requirements for sharding, replication or physical multi-tenant isolation that a relational database can only fake expensively. Conversely, "Milvus sounds more professional" or a feature you have not actually needed yet is not a reason. Migration costs an index rebuild, a dual-write verification period and a staged cutover — worth paying for a real bottleneck, not for architectural aesthetics.
Where this applies
People also ask
How accurate can an enterprise RAG knowledge base actually be?
Should an enterprise knowledge base use RAG or a fine-tuned LLM?
What server specs do you need to self-host a large language model?