Choosing a Vector Database: In‑Depth Comparison of Milvus, pgvector, and Qdrant

After building several Retrieval‑Augmented Generation (RAG) systems, the author reflects on the challenges faced when selecting a vector database and presents a side‑by‑side evaluation of three popular options.

pgvector was the quickest to get running because it is a PostgreSQL extension; the demo was completed in under an hour. It performs well for tables under one million rows (up to about five million) but latency grew from 30‑40 ms to over 2 seconds when the table reached 20 million vectors, which was resolved by sharding. For indexing, IVFFlat builds faster and uses less memory, while HNSW offers higher recall and lower query latency at the cost of slower build time and higher memory usage.

Milvus offers a rich ecosystem with more than twenty index types (e.g., FLAT, IVF_FLAT, IVF_SQ8, IVF_PQ, HNSW, DISKANN, SCANN) and client libraries for Java, Python, and Go. In production‑grade Cluster mode it depends on etcd, object storage, and message queues, making operations complex. The author recommends Milvus only when data volumes reach tens of millions to billions and a dedicated maintainer or outsourced team is available; for local testing or small‑scale validation the standalone mode is sufficient.

Qdrant , written in Rust, positions itself between pgvector and Milvus. It avoids the heavy dependencies of Milvus while providing better performance than pgvector for larger workloads. A friend’s company runs 50 million vectors with query latencies of a few tens to a few hundred milliseconds and appreciates Qdrant’s intuitive point + vector + payload model for filtered searches in multi‑tenant RAG scenarios. The downsides are a newer ecosystem and limited Chinese documentation.

The article includes two comparison tables (shown as images) that summarize dimensions such as scalability, maintenance effort, index options, and typical latency ranges for each product.

Key takeaways: do not judge solely by raw performance; consider data volume, vector dimensionality, top‑K size, filter complexity, recall requirements, concurrency, hybrid search needs, and update frequency. Start with pgvector for rapid prototyping, then migrate to Qdrant or Milvus as data grows, while continuously monitoring growth trends.