pgvector vs Dedicated Vector Databases: Which One Do You Need
A surprising number of enterprise RAG projects provision a dedicated vector database before they have a workload that needs one. pgvector, the vector extension for Postgres, handles millions of vectors with sub-100-millisecond query latency on modest hardware, and it keeps vector search transactionally consistent with the source-of-truth data you already store in Postgres. Dedicated vector databases like Milvus, Qdrant, and Weaviate exist because at sufficient scale, query throughput, or filtering complexity, a general-purpose relational database's vector extension starts to strain. The honest answer to which one you need depends on vector count, queries per second, team size, and whether you are willing to operate an additional stateful system in production. This comparison covers the operational tradeoffs vendors do not lead with.
What pgvector Actually Gives You
pgvector adds approximate nearest neighbor indexes, HNSW and IVFFlat, directly inside Postgres, so vector similarity search runs in the same database as your relational data with the same backup, replication, and access-control tooling your team already operates. This matters more than it sounds: a vector search that can join against a permissions table in the same query, inside the same transaction, is architecturally simpler and harder to get wrong than one that requires syncing permission state into a separate vector store's payload filters. For corpora up to a few million chunks, pgvector with an HNSW index comfortably delivers the recall and latency enterprise RAG systems need, and it means one fewer production system for your team to monitor, patch, and secure.
Where pgvector Starts to Hurt
HNSW index build time grows non-trivially past roughly 5 to 10 million vectors, and rebuilding the index after a bulk re-embed can take hours on a single Postgres instance without dedicated tuning. Memory pressure is the other real constraint: HNSW indexes are memory-hungry, and a large vector column competing with your transactional workload for the same buffer cache can degrade both. pgvector also has no built-in horizontal sharding, so scaling past what a single well-provisioned instance can hold means either read replicas with their own consistency tradeoffs or a migration to a system designed for horizontal scale from the start. None of this is a defect; it is simply the ceiling of retrofitting vector search onto a system built for something else.
- Index build and rebuild time grows meaningfully past 5 to 10 million vectors on a single instance
- HNSW indexes compete with your transactional workload for memory and buffer cache
- No native horizontal sharding, so scale-out requires an architecture change, not a config change
Milvus, Qdrant, and Weaviate: What Each Optimizes For
Milvus is built for scale first, with distributed architecture and GPU-accelerated indexing that pays off at hundreds of millions to billions of vectors, at the cost of a genuinely heavier operational footprint, multiple services to run and monitor, and a steeper learning curve for a team that has never operated it. Qdrant is written in Rust, tends to be simpler to self-host than Milvus, and has strong payload filtering that makes metadata-scoped queries (by tenant, department, or document type) fast and expressive. Weaviate ships hybrid search, combining vector and keyword retrieval, as a built-in feature rather than something you assemble yourself, and its module system covers reranking and generation hooks out of the box, which shortens time to a working hybrid pipeline at the cost of more opinionated architecture.
- Milvus: highest ceiling for scale, heaviest operational footprint, GPU-accelerated indexing
- Qdrant: simpler self-hosting, strong metadata payload filtering, solid default for mid-scale deployments
- Weaviate: built-in hybrid search and module ecosystem, more opinionated architecture in exchange
Decision Framework: Vector Count, QPS, and Team Size
Choose pgvector by default if your corpus is under roughly 5 million chunks, query volume is under a few hundred queries per second, and your team already runs Postgres in production, since the operational cost of a new system usually outweighs the marginal performance gain at that scale. Move to a dedicated vector database when you cross those thresholds, when you need advanced filtering combined with vector search that pgvector's SQL-based filtering handles awkwardly at scale, or when a single index needs to span data isolated across many tenants with strict performance guarantees per tenant. Team size matters as much as data size: a two-person platform team is often better served staying on pgvector even at moderate scale, simply because they cannot absorb the operational overhead of a second stateful system.
How Netray Chooses the Vector Store for Each Client
Netray's DataRay platform ships with pgvector as the default vector store for exactly the reasons above: fewer moving parts, tighter integration with existing Postgres-based access control, and it is enough for the large majority of client corpora. We instrument query latency, index build time, and recall from day one, and when a client's corpus or query volume genuinely outgrows pgvector, we migrate to Qdrant or Milvus with the evaluation harness already in place to confirm the migration did not regress accuracy. We do not lead with a dedicated vector database recommendation until the client's own numbers justify the added operational cost.
Frequently Asked Questions
Does pgvector scale to enterprise workloads?
Yes, for the majority of enterprise RAG corpora. pgvector handles millions of vectors with sub-100-millisecond query latency using HNSW indexes, and it keeps vector search transactionally consistent with your relational data. It starts to strain past roughly 5 to 10 million vectors, where index build time and memory pressure on a single instance become real operational concerns, at which point a dedicated vector database becomes worth the added complexity.
When should you move from pgvector to a dedicated vector database?
Move when your corpus exceeds roughly 5 million vectors, query throughput exceeds a few hundred queries per second, or you need advanced metadata filtering combined with vector search that strains Postgres SQL-based filtering at scale. Team operational capacity matters too: only take on a second stateful production system when the performance ceiling of pgvector is the actual bottleneck, not a hypothetical future one.
Is Milvus overkill for a mid-sized enterprise RAG deployment?
Usually, yes. Milvus is built for hundreds of millions to billions of vectors with a distributed, multi-service architecture that carries real operational overhead. Most mid-sized enterprise corpora, in the low millions of chunks, are better served by pgvector or Qdrant, both of which deliver strong recall and latency with a far smaller operational footprint. Reserve Milvus for genuinely large-scale, high-throughput retrieval workloads.
Should vector databases be self-hosted or managed for enterprise RAG?
For regulated manufacturers and defense suppliers, self-hosted is usually required, since managed vector database services introduce a third party into the data path that may conflict with ITAR, CMMC, or DFARS obligations. For less regulated workloads, a managed offering can reduce operational burden, but confirm data residency, retention, and subprocessor terms before committing to any vendor that touches document content or embeddings.
Key Takeaways
- 1What pgvector Actually Gives You: pgvector adds approximate nearest neighbor indexes, HNSW and IVFFlat, directly inside Postgres, so vector similarity search runs in the same database as your relational data with the same backup, replication, and access-control tooling your team already operates. This matters more than it sounds: a vector search that can join against a permissions table in the same query, inside the same transaction, is architecturally simpler and harder to get wrong than one that requires syncing permission state into a separate vector store's payload filters.
- 2Where pgvector Starts to Hurt: HNSW index build time grows non-trivially past roughly 5 to 10 million vectors, and rebuilding the index after a bulk re-embed can take hours on a single Postgres instance without dedicated tuning. Memory pressure is the other real constraint: HNSW indexes are memory-hungry, and a large vector column competing with your transactional workload for the same buffer cache can degrade both.
- 3Milvus, Qdrant, and Weaviate: What Each Optimizes For: Milvus is built for scale first, with distributed architecture and GPU-accelerated indexing that pays off at hundreds of millions to billions of vectors, at the cost of a genuinely heavier operational footprint, multiple services to run and monitor, and a steeper learning curve for a team that has never operated it. Qdrant is written in Rust, tends to be simpler to self-host than Milvus, and has strong payload filtering that makes metadata-scoped queries (by tenant, department, or document type) fast and expressive.
Put this into numbers
Free interactive tools for exactly this problem. No signup to use them.
RAG Infrastructure Sizing Calculator
Estimate vector storage, node RAM, generation GPUs, and monthly infrastructure cost for a retrieval-augmented generation deployment over your document corpus.
Free ToolRAG Chunking Strategy Calculator
Turn corpus size, chunk length, and overlap into a concrete chunk count, embedding cost, and vector storage footprint before you build the ingestion pipeline.
Free ToolEmbedding Model Serving Cost Calculator
Estimate the GPU hours and dollar cost to embed your daily document volume, factoring in embedding model size, batching efficiency, and re-indexing overhead.
Terms used in this article
Deciding between pgvector and a dedicated vector database for your RAG build? Netray will benchmark both against your actual corpus and recommend the one your numbers support.
Related Resources
Enterprise RAG Architecture: The Full 2026 Blueprint
A practitioner's blueprint for enterprise RAG in 2026: ingestion, chunking, embedding, retrieval, rerank, generation, and the eval loop that keeps it honest.
AI & AutomationHybrid Search: Combining BM25 and Vector Retrieval with RRF
Hybrid search for RAG: why pure vector retrieval misses exact matches, how BM25 fixes it, and how reciprocal rank fusion combines both reliably.
AI & AutomationRAG Cost Optimization: Cutting Spend Without Losing Accuracy
Practical RAG cost optimization: cheaper embedding models, caching, smaller rerankers, prompt compression, and when self-hosting beats API spend.