Milvus vs pgvector

Milvus and pgvector represent two ends of the operational spectrum. Milvus is a distributed, purpose-built vector database with a managed cloud (Zilliz); pgvector is a small PostgreSQL extension. The choice usually comes down to scale and whether you want to add a new database to your stack.

Where Milvus wins

• Widest ANN index zoo and billion-vector scale. HNSW, IVF, DiskANN, SCANN, GPU-CAGRA. pgvector offers HNSW and IVFFlat — sufficient for tens of millions of vectors, painful past that.

• Distributed architecture with separated storage and compute. Zilliz Cloud serverless scales storage and query independently. Postgres scales vertically by default.

• Multi-vector hybrid search with pluggable rerankers. Native support for combining dense, sparse, and multi-vector fields with RRF or weighted fusion in one query.

Where pgvector wins

• One database, one backup, one auth story. Vectors live with users, documents, and audit logs. ACID and joins work as you'd expect.

• Row-level security enforces multi-tenancy in the database. Milvus's partition keys provide isolation but enforcement is application-side.

• Lower operational complexity. pgvector adds an extension. Production Milvus depends on etcd, MinIO/S3, and Pulsar/Kafka — or you outsource to Zilliz Cloud.

The agentic difference

For agents over very large corpora where vector retrieval is the dominant workload, Milvus's distributed architecture and index choice deliver lower latency per dollar at scale pgvector cannot match. For agents where vector retrieval is just one tool among many alongside relational reads and writes, pgvector keeps everything in one database with one security model and one observability story. Milvus does not yet ship a first-party MCP server; pgvector relies on community wrappers.

When to pick which

• Pick Milvus when corpus size exceeds tens of millions of vectors, you need index choice, or you're standardizing on Zilliz Cloud.

• Pick pgvector when you already run Postgres and want vectors inside the same transactional and security boundary.