Vector Database Selection: A Practical Evaluation of pgvector vs Qdrant vs Milvus

Nine out of ten people building RAG systems have wrestled with the question of which vector database to use. Most comparisons on the market list a pile of benchmark scores and leave you even more confused, because benchmarks are meaningless without the context of your workload. This article is not about which database is fastest. It explains how to choose one for your scenario.

1. Start by asking yourself three questions

Before choosing a database, answer these three questions. Your answers will immediately eliminate half the candidates:

1. How much data do you have? 10,000 records, 1 million, or 100 million? This determines whether a lightweight option will work.
2. Who will operate it? Are you willing to deploy and manage it yourself, or do you only want to call an API? This determines self-hosted vs managed.
3. Do you need hybrid search (vectors + keywords)? Nearly every production RAG system does. This eliminates tools that support only pure vector search.

Keep these three questions in mind as you read the sections below.

2. Where the five mainstream options fit

These options are not mutually exclusive. Many teams "use Chroma/pgvector in development and Qdrant in production."

3. Recommendations by scenario

Scenario A: Personal project / internal tool / fewer than 1 million records

→ pgvector. If you already use PostgreSQL, do not overthink it. One CREATE EXTENSION vector gives you vector search, and you can JOIN against application tables. For a filter such as "perform semantic search only over my own unpublished notes," pgvector handles it with one SQL query, while a pure vector database requires additional metadata-filtering work.

For fewer than 1 million records and recall latency in the tens of milliseconds, pgvector is entirely sufficient. Combine PostgreSQL's built-in full-text search with RRF for hybrid retrieval, with no additional components.

Scenario B: Medium scale (millions to tens of millions), with low latency and powerful filtering

→ Qdrant. Written in Rust, it delivers stable latency and efficient memory usage. Payload filtering, which filters by metadata before vector search, is one of its strengths. This is exactly the pattern most often used in production RAG. A single node can comfortably handle tens of millions of records, and clustering is also available. The API is easy to use, and one Docker command starts the service.

Scenario C: Massive scale (hundreds of millions), high write volume, and distributed deployment

→ Milvus. When you genuinely have hundreds of millions of vectors, or write throughput exceeds what a single node can handle, Milvus's distributed architecture is the right choice. The tradeoff is heavy deployment and operations, with etcd, MinIO, and numerous other dependencies. Small teams may struggle with it. Do not use it below this scale. It is overkill for a small workload, and the operational cost far exceeds the benefit.

Scenario D: You want no operational burden, need elasticity, and have enough budget

→ Pinecone or a similar managed vector service. You only need to call an API; it scales elastically, and you do not have to manage index rebuilding. It suits enterprise teams that need to "launch quickly without staffing infrastructure." Be aware that it is expensive, with pricing based on pods or usage. You must also confirm cross-border data compliance, and it creates vendor lock-in.

Scenario E: Prototype / local experiment

→ Chroma, or simply SQLite + sqlite-vec. A few lines of code get it running, with no service to launch. Use it only during prototyping, then migrate once you reach production or meaningful scale.

4. The overlooked selection criterion: hybrid-search support

Production RAG systems almost always require hybrid vector + keyword search, because pure vector retrieval performs poorly on exact strings. Support varies substantially across databases:

• pgvector: Combine it with PG full-text search for native fusion in the same database and a single SQL query.
• Qdrant: Supports sparse vectors, enabling dense + sparse retrieval in the same database.
• Milvus: Supports hybrid search.
• Chroma / Pinecone: Hybrid-search support is relatively weak or requires external components.

If you know you need hybrid search, and you probably do, this criterion alone can eliminate several candidates.

5. A pragmatic migration path

Many people get stuck worrying that choosing incorrectly will make migration difficult. In practice, the abstraction layer for a vector database is thin. A good approach is:

• Make application code depend on a single abstraction interface (search(query, k) → hits), with pgvector or Qdrant treated as an implementation detail.
• Embedding vectors are standard assets: they are independent of any specific vector database. You can reuse them during migration and only need to ingest them again.
• Always retain the source data (the original documents). In the worst case, migration means rebuilding the index from the original documents, which is not a disaster.

This lets you start with pgvector and migrate to Qdrant or Milvus when you reach a bottleneck, with manageable costs.

6. Pitfalls to avoid

1. Blindly chasing "the fastest." Vector search is usually not the bottleneck in an end-to-end RAG pipeline; chunking and reranking have a greater impact. Replacing an entire operational stack for a database that is 5 ms faster is not worth it.
2. Ignoring filtering performance. Many real queries are vector searches with filters, such as restricting results to a particular user or time range. Some databases suffer a dramatic performance drop after filtering, which benchmarks may not reveal.
3. Overusing distributed systems. If one machine can handle the workload, do not deploy a distributed system. The operational complexity of a distributed vector database increases exponentially.

Summary

The right way to choose a vector database is to define the scenario first, including scale, operations, and hybrid search, and then choose the database.

• Existing PG deployment, small to medium scale → pgvector
• Medium to large scale, with low latency and filtering → Qdrant
• Hundreds of millions of records and high throughput → Milvus
• Minimal operations and sufficient budget → Pinecone
• Prototype → Chroma / sqlite-vec

pgvector is the most underrated option. Most projects are nowhere near its ceiling, yet they adopt a heavier vector database from the outset and create unnecessary operational overhead. Starting with an option you can operate comfortably and upgrading when the business genuinely requires it is far smarter than "designing for the future" from day one.