pgvector vs Milvus for production AI: Which Should You Use?

pgvector is a PostgreSQL extension for vector search. Milvus is a purpose-built vector database built to handle large-scale similarity search and retrieval workloads. If you are building production AI and already run PostgreSQL, start with pgvector; if your vector workload is core infrastructure at serious scale, use Milvus.

Quick Comparison

When pgvector Wins

• •

  Your application already depends on PostgreSQL

  If your source of truth is Postgres, pgvector keeps embeddings next to the rows they describe. That means fewer sync jobs, fewer consistency bugs, and simpler backups.

• •

  You need SQL joins around vector search

  This is where pgvector beats most vector databases in real projects. You can filter by tenant, status, language, permissions, or timestamps in the same query:

  SELECT id, title
  FROM documents
  WHERE tenant_id = $1
    AND status = 'active'
  ORDER BY embedding <-> $2
  LIMIT 10;
  

• •

  You want one operational stack

  Production teams do not fail because of model choice alone; they fail because of too many systems. pgvector lets you avoid introducing a second datastore just to store embeddings.

• •

  Your scale is real but not massive

  For thousands to low millions of vectors per tenant or use case, pgvector is usually enough if you index correctly with HNSW or IVFFlat and keep your schema disciplined.

When Milvus Wins

• •

  Vector search is the product

  If similarity search sits on the critical path for every request, Milvus is the right tool. It is designed for retrieval-first systems instead of being an extension attached to a general-purpose database.

• •

  You have large-scale corpus sizes

  Once you are dealing with tens of millions or hundreds of millions of vectors across tenants or domains, Milvus starts making more sense than pushing Postgres harder than it wants to go.

• •

  You need aggressive throughput and latency targets

  Milvus handles concurrent ANN workloads better because it was built around that problem space. If your SLO says sub-100ms retrieval at high QPS under load spikes, use Milvus.

• •

  You expect retrieval infrastructure to evolve independently

  In larger orgs, embedding schemas change often: new models, new dimensions, new filters, new rerankers. Milvus gives you a cleaner separation between transactional data and retrieval infrastructure.

A typical Milvus flow looks like this:

from pymilvus import Collection

collection = Collection("documents")
collection.load()

results = collection.search(
    data=[query_vector],
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"ef": 64}},
    limit=10,
    output_fields=["title", "tenant_id"]
)

That separation matters when the retrieval layer has its own scaling profile.

For production AI Specifically

Use pgvector unless you have a hard reason not to. Most production AI apps are not actually vector-database problems; they are application problems with embeddings added on top of existing transactional data.

Choose Milvus only when vector retrieval is a first-class subsystem with serious scale demands. If your team already runs Postgres well and needs reliable RAG or semantic search now, pgvector gets you shipping faster with less operational risk.

Keep learning

• •The complete AI Agents Roadmap — my full 8-step breakdown
• •Free: The AI Agent Starter Kit — PDF checklist + starter code
• •Work with me — I build AI for banks and insurance companies

By Cyprian Aarons, AI Consultant at Topiax.