What Each Tool Is and How It's Architected
Milvus is a purpose-built, open-source vector database designed to run anywhere from a laptop to a large distributed cluster. Its cloud-native architecture separates compute from storage and decouples responsibilities across query nodes, data nodes, index nodes, and coordinators, with object storage (MinIO or S3), a metadata store (etcd), and a message queue (Pulsar or Kafka) underneath. This decoupling lets each layer scale independently, which is the source of Milvus's headroom. Deployment comes in three flavors: Milvus Lite for prototyping, Standalone via Docker for single-machine use, and Distributed on Kubernetes for production at scale.
pgvector takes the opposite approach. Rather than a standalone service, it is an extension that adds a native vector data type and similarity search to PostgreSQL. You install it with CREATE EXTENSION vector, add a vector column to an existing table, and query it with ordinary SQL. There is no separate engine, no coordinator, and no message queue: vectors live in the same database as your relational rows and inherit Postgres's ACID guarantees, replication, and point-in-time recovery. For teams already running Postgres, pgvector turns semantic search into a schema change rather than a new piece of infrastructure to stand up and operate.
Indexing and Retrieval Features
Milvus offers the broadest index catalog of the two. It supports exact FLAT search, IVF families (IVF_FLAT, IVF_SQ8, IVF_PQ) for quantized in-memory retrieval, graph-based HNSW and its quantized variants, SCANN, and on-disk DiskANN for datasets larger than RAM. It also ships GPU indexes, including NVIDIA CAGRA, GPU_IVF_FLAT, and GPU_IVF_PQ, for very high-throughput workloads. Beyond plain ANN, Milvus does filtered search, range search, multi-vector hybrid search, sparse vectors, and built-in full-text BM25, with boolean scalar filtering on metadata. The breadth lets you tune the recall-latency-memory triangle precisely for demanding retrieval scenarios.
pgvector covers the indexes most applications actually need: HNSW for fast, high-recall queries and IVFFlat for lower-memory builds, plus exact search by default when no index exists. It supports six distance operators (L2, inner product, cosine, L1, and Hamming/Jaccard for binary vectors) and additional types like halfvec, bit, and sparsevec. Standard indexing handles up to 2,000 dimensions, extending to 4,000 with half-precision and higher with binary quantization. The catalog is narrower than Milvus's, but for typical embedding models of 768 to 1,536 dimensions, HNSW on pgvector delivers competitive recall and latency.
Operations, Scaling, and SQL Hybrid
This is where the architectures diverge most. Milvus scales horizontally: because storage and compute are separated and nodes are decoupled, you can add query nodes for QPS or index nodes for build throughput, and the system is documented running from billions into tens of billions of vectors. That power comes with operational surface area, since etcd, object storage, and a message queue must all stay healthy, and disks dedicated to etcd need 500+ IOPS with sub-10ms fsync latency. Running Milvus Distributed well means running Kubernetes and treating the database as a real distributed system.
pgvector scales vertically inside a single Postgres instance, so throughput and index build times are bound by that server's CPU, RAM, and maintenance_work_mem; very large HNSW indexes are memory-hungry to build. What you gain is a genuine SQL hybrid: vector similarity sits in the same query as WHERE filters, JOINs, aggregates, and row-level security, all transactionally consistent. A query that orders by embedding distance combined with a tenant filter needs no data sync between systems. For most RAG and MVP workloads, one well-provisioned Postgres handles the vector volume comfortably.
Deployment and Cost
Milvus's cost profile follows its architecture. Self-hosting Milvus Lite or Standalone is cheap for experiments, but production Distributed deployments carry the cost of a Kubernetes cluster plus the compute, memory, and object storage each node consumes, and the engineering time to operate them. GPU indexes add accelerator costs on top. To avoid that burden, Zilliz Cloud offers fully managed Milvus, trading operational overhead for a subscription. The total cost of ownership makes sense when your scale or QPS genuinely needs a dedicated, independently scalable vector tier that a single relational database cannot serve.
pgvector's cost is largely absorbed by infrastructure you already pay for. If Postgres is your system of record, adding vectors means provisioning more RAM and disk on that instance rather than standing up and staffing a second data store. Managed Postgres providers such as Supabase, Neon, and RDS ship pgvector as a toggle, so there is no new vendor relationship or cluster to learn. For small-to-mid workloads this consolidation is the decisive economic advantage: fewer moving parts, one backup and monitoring story, and no cross-system data pipeline to build or maintain.
When Each Tool Wins
For the typical aicoolies reader (OSS-first, already on Postgres, shipping a RAG feature or an MVP) pgvector is the pragmatic default. Keeping embeddings next to relational data collapses two systems into one: a single database to secure, back up, and reason about, with vector search expressed as ordinary SQL. Up to the low tens of millions of vectors on a well-sized instance, pgvector's HNSW gives strong recall and latency without a distributed cluster. You reach for it when simplicity, transactional consistency, and operational economy matter more than raw ceiling.
When Milvus wins: choose Milvus once scale or throughput outgrows a single Postgres. Concretely, that means roughly 100M+ vectors, sustained very high QPS, or strict low-latency targets that demand independently scaled query nodes; workloads needing GPU-accelerated indexes (CAGRA) or on-disk DiskANN for datasets larger than RAM; or an organization that wants a dedicated vector tier with advanced ANN operations, multi-vector hybrid search, and elastic horizontal scaling. If you already run Kubernetes and have platform engineers, Milvus's operational cost is easier to justify. At that scale, its purpose-built engine is the safer bet.
Verdict and Adoption Path
For most readers, pgvector leads in daily production adoption. It delivers vector search where your data already lives, with the least new infrastructure and the strongest consistency guarantees: the right first choice for RAG apps, MVPs, and the large majority of production workloads that never exceed a single capable Postgres instance. Milvus is not the loser so much as the specialist, the tool you graduate to when scale, QPS, or GPU indexing genuinely demand a dedicated distributed engine. Picking pgvector first does not close that door.
A clean adoption path starts with pgvector: enable the extension, add a vector column, build an HNSW index, and combine similarity search with your existing SQL filters. Instrument recall, p95 latency, and index build time as your corpus grows. If you approach the tens-of-millions mark, need GPU indexes, or see a single Postgres straining under vector QPS, evaluate Milvus (self-hosted on Kubernetes or via managed Zilliz Cloud) and migrate the vector workload while keeping relational data in Postgres. Start simple, measure, and scale up only when the numbers say so.