Milvus vs pgvector: which to choose

Milvus vs pgvector: when each one fits your private AI stack

If your team already runs PostgreSQL and your vector workload is moderate, pgvector is usually the lower-effort choice. It is a PostgreSQL extension under the PostgreSQL License, so vectors sit in the same database as your users, documents and permissions, and you back them up, patch and monitor them with the tooling you already use. pgvector supports exact search by default, adds HNSW and IVFFlat approximate indexes, and indexes vector columns of up to 2,000 dimensions. The condition that matters is scale and query shape: if your collections stay within what one PostgreSQL cluster serves well for your latency target, and your queries join vectors to relational tables, the extra database is rarely worth adding. Confirm the index build and memory needs against your own row counts before you commit, because pgvector's approximate indexes are a tuning exercise of their own.

Milvus fits when the vector workload is the primary system rather than a column on an application database. It is built for large collections, multi-tenancy across databases, collections, partitions or partition keys, and disaggregated scaling, where proxies, coordinators and worker nodes can be sized separately. Milvus is Apache-2.0 licensed and supports HNSW, IVF, FLAT, SCANN and DiskANN indexes, BM25 full-text search and hybrid dense plus sparse search. The cost is operational: the distributed architecture uses etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log built on Woodpecker, Kafka or Pulsar. Those are reasonable dependencies when you can staff them and need the scaling they buy. For a single-team prototype or a modest collection, Milvus Lite or Standalone may be the better first step, as covered elsewhere on this page.

Which scenarios favor pgvector and which favor Milvus

This table maps common private AI scenarios to the option that fits better and the condition under which the other one wins. Read each row against your vector count, your existing PostgreSQL estate and how much operating work your team can carry.

Scenario	Better fit	Why and when the other option wins
Existing PostgreSQL estate with modest vector counts	pgvector	Vectors sit in the database you already back up, monitor and patch, so there is no second data store to operate. Milvus wins once collection size, query volume or ingest rate outgrows what one PostgreSQL cluster serves comfortably. Confirm capacity with a load test on your own data.
RAG tied to transactional records	pgvector	Joining embeddings to customer, contract or case rows in one SQL statement keeps access rules and record updates in a single place. Milvus wins when retrieval must span many sources and the relational join is a small part of the query.
Filtered search on attribute-heavy queries	pgvector	Filters are ordinary SQL predicates, and pgvector's iterative index scans help when filters remove many candidates. Milvus wins when filtered queries run at high concurrency and you need its partition key and collection-level controls.
Large multi-tenant collections	Milvus	Milvus offers tenancy at database, collection, partition or partition key level, which suits many tenants with very different sizes. pgvector can isolate tenants with schemas or row-level policies, but this takes more design and tuning at high tenant counts.
Independent scaling of storage and compute	Milvus	Milvus separates stateless proxies, coordinators and workers, with object storage and a write-ahead log behind them. This justifies running etcd, object storage and a message queue only when growth or ingest bursts need components scaled separately. Small teams rarely need that split.
Hybrid dense and sparse search with BM25	Milvus	Milvus documents BM25 full-text search, sparse vectors and hybrid search in one engine. pgvector can combine vector and PostgreSQL full-text search, which is often enough for modest corpora. Confirm the ranking quality you need on your own documents.
Team with limited platform operations capacity	pgvector	A PostgreSQL extension inherits your existing backup, replication and upgrade routines. Milvus Distributed adds etcd, object storage and a write-ahead log to run, so it fits teams with dedicated platform engineers or a support retainer.
Strict data location and self-hosting requirements	Either	Both are open source and run in your own infrastructure. The deciding factor is the operational load each one adds to your environment, not license terms, since both are Apache-2.0 or PostgreSQL License.

How pgvector and Milvus are built and what each means for operations

pgvector adds vector search to a PostgreSQL server you already operate, so its operating model is the one your database team already knows. Milvus splits storage, metadata and compute into separate services, which changes what you upgrade, back up and watch at night.

pgvector as a PostgreSQL extension

pgvector runs inside the PostgreSQL server, so vectors sit in the same database as your relational tables. Exact nearest neighbor search is the default, and HNSW or IVFFlat indexes are added per column when you need approximate search. Check that your current PostgreSQL major version is one your team can keep supported, because pgvector inherits that lifecycle. The vector and relational data then share one backup and restore path.

Milvus disaggregated design

Milvus separates stateless proxies, a coordinator, and worker nodes, so each layer can be scaled and restarted on its own. Metadata lives in etcd and vector data in object storage such as MinIO, S3 or Azure Blob. Your team must run and monitor each of these components, not a single database server. Ask your vendor or your own platform team which deployment mode you will run before you size the cluster.

Write-ahead log choice

Milvus writes incoming data through a write-ahead log, which can be Woodpecker, Kafka or Pulsar depending on the deployment. That choice adds a streaming component with its own storage, retention, and failure modes. Your on-call runbook must cover what happens when the log backs up or a broker is unavailable. pgvector writes through PostgreSQL's own write-ahead log, so there is no separate queue to operate.

Upgrades and release lines

PostgreSQL minor releases do not change the storage format, so updating means replacing executables and restarting. Major upgrades use dump and restore, pg_upgrade, or logical replication, and logical replication can keep downtime to several seconds. Milvus publishes two active release lines, so you must choose a line and plan migrations between the components. Confirm the upgrade path for your exact versions with the Milvus maintainers before you commit.

Backups and recovery scope

A pgvector backup captures vectors with the rest of your data, so point-in-time recovery applies to both at once. A Milvus backup must keep etcd metadata, object storage and the write-ahead log consistent with each other. Test a full restore of each system, not just the snapshot job. Ask your team to document the recovery order and who owns each store.

On-call and failover ownership

PostgreSQL does not detect a primary failure on its own, so automatic failover needs external tooling your team must select and operate. Milvus failure handling spans proxies, coordinators, workers, etcd and object storage, each with its own alerts. Decide before go-live which team answers for each layer and how many services a single incident can touch. The smaller set of moving parts in pgvector usually means a shorter escalation path.

How index types, filtering and multi-tenancy compare

This table sets pgvector's exact and approximate indexes against Milvus's index menu, filtering, search modes, tenancy levels and access controls. Read each row as a question to answer for your own workload, since the right choice depends on vector count, filter selectivity and how many tenants share the data.

Capability	pgvector (PostgreSQL extension)	Milvus
Index types	Exact search by default, plus HNSW and IVFFlat approximate indexes	HNSW, IVF, FLAT, SCANN and DiskANN, plus GPU indexing with NVIDIA CAGRA
Distance metrics	L2, inner product, cosine, L1, Hamming and Jaccard operators	Confirm the full metric list for your chosen index in the Milvus documentation
Vector dimensions	Indexed vector columns up to 2,000 dimensions; vector and halfvec types up to 16,000	Confirm dimension limits per index and version against the Milvus documentation
Filtering behavior	Filters apply after the index scan; iterative index scans can fetch more rows when filters remove too many	Filtering is handled inside the vector engine; confirm behavior under your filter selectivity in testing
Full-text and hybrid search	Keyword ranking is not a built-in index type in the supplied facts; confirm any full-text setup you plan to use with PostgreSQL features	BM25 full-text search, sparse vectors and hybrid dense plus sparse search
Multi-tenancy levels	Tenancy follows PostgreSQL schemas, roles and row-level design you build yourself; confirm the isolation model you need	Database, collection, partition or partition key level
Authentication, TLS and RBAC	PostgreSQL authentication methods include password, GSSAPI, LDAP, certificate, PAM and OAuth	Authentication, TLS encryption and role-based access control are implemented
Version support	Supports PostgreSQL 13 and later; PostgreSQL 14 support ends November 12, 2026	Two release lines: v3.0.3 (October 14, 2026) and v2.6.25 (September 29, 2026)

Licensing and editions: what is free, what is paid

Milvus is licensed under the Apache License 2.0, and the project operates under the LF AI and Data Foundation with Zilliz as its primary contributor. That combination means the core database can be used, modified and redistributed under a permissive license, and no paid edition of the server software gates features such as distributed deployment, access control or multi-tenancy. The project's own README describes authentication, TLS encryption and role-based access control as part of the open source release.

License terms: Apache-2.0 covers the Milvus codebase, so your legal team reviews the standard patent and notice obligations rather than a custom commercial agreement.
Governance: Foundation hosting under LF AI and Data Foundation is a governance arrangement, not a support contract, so no foundation SLA comes with it.
Maintainer concentration: Zilliz is the primary contributor, so ask how the project's roadmap and security fixes are handled if that contribution pattern changes.
Release lines: Two lines are maintained, v3.0.3 and v2.6.25, so confirm which one your upgrade plan targets.
Managed options: Zilliz Cloud offers Serverless, Dedicated and bring-your-own-cloud deployments. These are paid services from the vendor, separate from the open source license.

Confirm with Zilliz the exact commercial terms of any managed option, and confirm with your legal team how Apache-2.0 notice requirements apply to your internal distribution.

Where pgvector filtering and joins stop being enough

pgvector keeps vectors in the same PostgreSQL database as your relational data, so a single query can combine a nearest-neighbor ordering with WHERE clauses and JOINs on tenant, permission, document status or date tables. For many RAG workloads this is the decisive advantage: the access rules that already live in PostgreSQL apply to the vectors without a second copy of the data or a sync job. The condition that matters is the shape of the query, not the vector count. If most retrievals filter on relational columns and join to tables you already maintain, pgvector's combined model usually beats a separate store, even at sizes where a dedicated engine would be faster in isolation.

The risk sits in approximate indexes. The pgvector README notes that with HNSW or IVFFlat, filtering is applied after the index is scanned, so a selective filter can return fewer rows than the LIMIT you asked for. The documented mitigation is iterative index scans, which can fetch more candidates when filters remove too many, in strict or relaxed ordering modes. Test this on your own data before go-live: run your most selective tenant and permission filters against realistic index settings, count the rows returned, and compare the result with an exact scan. Confirm the iterative scan settings available in the PostgreSQL and pgvector versions you run, and record the recall you accept for each query class.

Move to a dedicated store when isolation and scale have to be structural rather than query-dependent. Milvus offers multi-tenancy at database, collection, partition or partition key level, which lets you give large tenants their own partitions and keep search from scanning unrelated data. That control costs services: a Distributed deployment adds etcd for metadata, object storage and a write-ahead log, and you must keep those synchronized with the relational source of truth. Ask the Milvus team and your own platform engineers whether that operating load is justified by tenant count, isolation requirements or collection size, and whether your joins can be moved into the application layer without weakening access control.

What drives running cost on each side

Running either option costs more than the software line item. Each card names a cost component, who gets paid for it and what to request in a quote, so the comparison reflects your own staffing and infrastructure rather than a licence fee alone.

Infrastructure and compute

With pgvector, vectors sit in the PostgreSQL instance you already pay to run, so the added cost is mostly memory and disk for HNSW indexes on that server. Milvus Distributed adds separate proxy, coordinator and worker nodes plus etcd and a write-ahead log, each with its own compute footprint. Ask a quote to size both options against your vector count, dimensions and query rate, and to list every node type it provisions.

Object storage and write-ahead log

Milvus stores segment data in MinIO, S3 or Azure Blob and writes changes through Woodpecker, Kafka or Pulsar before they are persisted. Each of these is a service someone must size, back up and monitor, and object storage usage is billed by the provider or the team that runs it. pgvector keeps vectors in ordinary PostgreSQL storage that your backup tooling already covers. Confirm who owns each of these services and what their storage charges look like in your environment.

Existing PostgreSQL skills

Minor PostgreSQL releases replace executables and restart the server without changing the storage format, and major upgrades can use pg_upgrade or logical replication, which works across major versions. Most database teams already run these procedures, so the effort is largely a scheduled task in an existing role. Ask whether your DBA team has run pgvector upgrades and whether the extension version is tested against each PostgreSQL major release you plan to use.

Kubernetes and etcd operations

Milvus Distributed is Kubernetes-native and depends on etcd for metadata, so cluster upgrades, etcd backups and node scheduling become recurring operational work. A team without Kubernetes operations experience will either hire for that skill or pay a services provider. Ask a quote who will operate the etcd quorum, how upgrades are rolled out and whether the statement of work covers the Kubernetes layer or stops at the Milvus pods.

Backups, recovery and replication tooling

PostgreSQL offers point-in-time recovery through continuous archiving and hot standby replicas, but automatic failover needs an external tool. Milvus backups must cover etcd, object storage and the log layer together so that a restore is consistent. Ask for the recovery procedure, the recovery time you can verify in your own test environment and the tools you must license or operate for failover on either side.

Support and implementation scope

Open-source releases carry no vendor support fee, so the recurring cost is the service you buy: implementation, upgrades, monitoring and on-call. DeployOpen works on fixed-scope engagements with ongoing support available as a retainer, and it does not publish a price list. Ask any provider for a written scope that names each component, the upgrade cadence and who responds when a node fails at night.

Moving vectors from pgvector to Milvus, or back

This sequence moves embeddings and their metadata between pgvector and Milvus without losing track of which records belong to which tenant. It ends with a verified cutover and a retired index, so the team can tell with evidence that the new store answers as well as the old one.

Inventory the schema, filters and tenant model
Before exporting anything, the platform team lists every table or collection that holds vectors, the dimensions and distance metric in use, the metadata columns that queries filter on, and how tenants are separated today, whether by schema, a tenant column, or row-level security. Milvus offers multi-tenancy at database, collection, partition or partition key level, so the team decides which of those maps to each existing tenant boundary. The step is done when a written mapping table exists and the data owner has signed off on it.
Export embeddings and metadata with source keys
The data engineering team exports each vector with its primary key, metadata columns and tenant identifier, using a query that reads from PostgreSQL in consistent batches. Every exported row keeps its original source key so that results can be traced back after cutover. Embeddings and metadata transfer as data; the vector index does not. The step is done when row counts and a checksum per batch match the source, and a sample of rows has been compared field by field.
Re-create collections, partitions and indexes
The platform team creates Milvus collections with the same vector dimensions and distance metric, sets up the partitions or partition keys chosen in the first step, and builds the index type that suits the workload, such as HNSW, IVF or DiskANN. Index parameters are tuned again because pgvector's HNSW and IVFFlat settings do not carry over. The step is done when each collection reports its expected entity count and the index build completes without errors on the target environment.
Load data and rebuild filters and access rules
Batches are inserted into Milvus, and the metadata fields used for filtering are declared so queries can apply them. Access rules are rebuilt on the Milvus side: database and collection users, roles, and TLS settings must be configured again, because role-based access in pgvector comes from PostgreSQL roles and row-level policies. Ingestion pipelines that write new embeddings also need to be repointed. The step is done when a test user sees only their own tenant's results and the ingestion job writes to Milvus in a dry run.
Validate recall and latency against the old index
A fixed set of held-out queries is run against both pgvector and Milvus, and the team compares top-k overlap (recall against exact search) and response times at expected concurrency. Filtered queries are tested separately, since pgvector applies filters after the index scan and may need iterative scans to return enough rows. The step is done when results meet thresholds the data owner and the application team agreed in writing before the test started.
Cut over reads and writes to Milvus
The application switches its read path to Milvus behind a configuration flag, while the write path keeps both stores in sync for a short overlap period. The team watches error rates, latency and result quality through the same dashboards used before the change. Rollback means flipping the flag back to pgvector, so the old data must stay intact during the overlap. The step is done when production traffic has run on Milvus for the agreed window with no unresolved quality or access issues.
Retire the pgvector index and document the result
Once the rollback window closes, the team drops the pgvector indexes and, if agreed, the vector columns, then records the final schema, index settings, tenant mapping and validation results in the runbook. Relational data stays in PostgreSQL where it belongs, so only the vector storage is removed. The reverse path, moving from Milvus back to pgvector, follows the same steps with the roles of the two stores swapped. The step is done when the runbook is signed off and the old index no longer serves queries or consumes storage.

Where Milvus and pgvector projects usually run long

Most delays on a Milvus or pgvector project come from decisions made before the first production load, not from installation. The first is index tuning. pgvector gives you exact search by default plus HNSW and IVFFlat indexes, and Milvus adds HNSW, IVF, FLAT, SCANN and DiskANN, each with its own parameters. Teams often spend weeks on recall and latency trials across embedding models and index settings. Agree the recall target, the query set and the acceptance test in the written scope before anyone starts tuning, and confirm which index types your chosen version and deployment mode actually support. For pgvector, also test filtered queries: the README notes that approximate indexes filter after the scan, so plan for iterative index scans when filters remove many candidates.

The second is data pipelines and re-embedding. Vectors are only as current as the pipeline that writes them, and changing an embedding model means re-embedding the whole corpus. On pgvector that work runs inside the PostgreSQL database you already operate, so it competes with transactional load and must respect the 2,000-dimension limit for indexed columns. On Milvus it runs through a write-ahead log (Woodpecker, Kafka or Pulsar) and object storage, which adds integration points to test. Ask who owns re-embedding, how source documents are deleted and how tenant data is removed on request. The third is access control and tenant design. Milvus offers multi-tenancy at database, collection, partition or partition key level and role-based access control, while pgvector inherits PostgreSQL roles and row-level policies. Decide the tenant boundary before loading data, because moving it later means reloading collections or rewriting policies.

The fourth, and often the longest, is running dependencies inside your own cloud or air-gapped network. A distributed Milvus cluster needs etcd for metadata, an object store such as MinIO, S3 or Azure Blob, and a message queue, each with its own backup, patching and monitoring. Confirm which of these your security team accepts, which images can be mirrored into a disconnected registry, and who restores the cluster after a failure. DeployOpen plans and documents this work in fixed-scope written agreements: scope, deliverables and timelines are agreed in writing before work starts, and the scope names the environment, the dependencies and the acceptance tests. Ask for the list of dependencies, the test plan and the handover documents in the quote so that the scope reflects your environment rather than a generic install.

Milvus vs pgvector questions buyers ask before hiring help

Which costs more to run, Milvus or pgvector?

pgvector usually adds the least new running cost when you already operate PostgreSQL, because it adds an extension to a database you already back up, monitor and patch. Milvus Distributed adds separate components: etcd for metadata, object storage such as MinIO, S3 or Azure Blob, a write-ahead log (Woodpecker, Kafka or Pulsar), and Kubernetes capacity. Each of these is a service your team must run, secure and upgrade. Recurring cost drivers are compute, storage growth, backup copies and on-call time. Ask any provider to itemize these components in a written quote, and compare against your own PostgreSQL hosting bill.

How much effort does self-hosting Milvus take?

Effort depends mostly on the deployment mode. Milvus Lite is a Python library for prototypes, Standalone runs on one machine, and Distributed is a Kubernetes-native cluster with several moving parts. Distributed means operating etcd, object storage, the message queue and the Milvus proxies, coordinators and worker nodes, plus capacity planning, TLS and role-based access control configuration, and version upgrades across the two release lines (v2.6.25 and v3.0.3 at the time of writing). Ask for a runbook covering backup, restore and failure testing for each dependency.

Is pgvector enough for vectors next to existing PostgreSQL data?

Often yes, when the vector count, query rate and filter patterns fit within what one PostgreSQL cluster handles well. pgvector stores vectors in the same database as your relational data, so joins, transactions and access controls stay in one place. Exact search is the default, and HNSW and IVFFlat indexes cover approximate search for vectors up to 2,000 dimensions in indexed columns. The pgvector README notes that filtering runs after the index scan, and iterative index scans can fetch more rows when filters remove too many. Test your own filtered queries at production volume before deciding.

How does switching from pgvector to Milvus work?

Switching is a data migration plus an application change. You export embeddings and their metadata, recreate collections with matching index and distance settings, load the data, and then change query code that previously used SQL operators. Plan for a period where both systems run so results can be compared. Costs come from re-embedding if the model changes, validating recall and filter results, and updating backup and monitoring. Moving the other direction is usually simpler when the data must return to relational joins. Ask any implementation partner for a migration plan with acceptance tests before work starts.

What does the work need from our own team?

Expect to supply people who already own PostgreSQL or Kubernetes, access to the cloud accounts or data center where the system runs, and a named owner for the data and access decisions. For pgvector, the database administrator usually owns schema, index build, backup and upgrades. For Milvus Distributed, you also need someone who can operate Kubernetes, object storage and the message queue. Name these owners in the written scope so review, sign-off and on-call responsibilities are clear before work begins.

Can our team do this work without outside help?

Yes, if you already run PostgreSQL or Kubernetes in production and have time to learn the vector-specific settings. pgvector is the smaller learning curve because the operational model is unchanged. Milvus Distributed adds etcd, object storage, a write-ahead log and cluster tuning, which new teams often underestimate. Outside help is most useful for the design decisions, hardening, backup and failure testing, and for documenting evidence. Scope it in writing, decide which parts you keep, and agree on handover criteria.

How do upgrade paths compare between the two?

PostgreSQL releases a new major version about once a year and supports each major version for five years, with minor releases at least every three months. Minor updates replace executables and restart, while major upgrades use dump and restore, pg_upgrade or logical replication, which can cut downtime to several seconds. pgvector 0.8.7 is an extension you upgrade alongside PostgreSQL. Milvus upgrades span its etcd, object storage and messaging dependencies as well as the cluster, so plan rehearsals and confirm the supported version path with the Milvus release notes before each change.

Official sources to check before you decide

Start with the release history for each product, because both projects move quickly and your decision should rest on the version you would actually deploy. The Milvus GitHub releases page lists two active lines, v3.0.3 (published October 14, 2026) and v2.6.25 (published September 29, 2026), so confirm which line your vendor support, client SDKs and Helm charts target before you pick one. On the pgvector side, check the pgvector CHANGELOG for the 0.8.7 release (October 1, 2026) and any breaking changes between your current extension version and the one you plan to run. Record the exact versions you tested so the comparison stays tied to something you can reproduce.

Next, read the Milvus architecture overview and map each component to a service you would have to run, back up and patch. The document describes stateless proxies, coordinators and worker nodes, etcd for metadata, object storage (MinIO, S3 or Azure Blob) and a write-ahead log (Woodpecker, Kafka or Pulsar). Ask your platform team who owns each of those systems, what their restore procedure is and whether that team already supports them. For pgvector, the main operational question is different: the vectors sit inside the PostgreSQL cluster you already back up, so confirm that your current backup, replication and upgrade runbooks cover the extension's indexes and that a rebuilt HNSW or IVFFlat index is acceptable in your recovery window.

Finally, check the PostgreSQL versioning policy against your own calendar. Version 14 is listed as supported only to November 12, 2026, and 15 to November 11, 2027, so a pgvector deployment on an older major version may force a database upgrade sooner than the vector project does. Decide who approves that upgrade and whether it is already scheduled. If you choose Milvus, confirm with Zilliz or your own support provider which release line and upgrade path they will sign up to, since the architecture and dependency set are the parts most likely to change between lines.

How DeployOpen helps choose, implement or migrate

DeployOpen approaches Milvus vs pgvector as a scoped infrastructure decision, starting from your data volumes, filtering needs and the PostgreSQL estate you already operate. We plan, build and document whichever option fits, inside your own cloud accounts, data centers or air-gapped networks, and we hand over the running system with its runbooks.

How we scope

Review vector counts, dimensions, filter patterns and tenancy needs against your existing PostgreSQL footprint
Agree in writing which Milvus deployment mode or pgvector setup is in scope, and what is excluded
Set out the services each option needs in production, such as etcd, object storage and a message queue for Milvus
Confirm the supported PostgreSQL major version and its end-of-support date before choosing a path

How we build

Deploy the chosen option in your environment with access control, TLS and authentication configured
Benchmark index type and filtered queries on your own data rather than on generic sample sets
Plan any migration between pgvector and Milvus, including reindexing and a rollback path
Test backup, restore and failover behavior against the services your chosen option actually depends on

How we hand over

Document architecture, configuration, index choices and dependency versions for your operations team
Deliver runbooks for upgrades, backups, scaling and incident response
Walk your engineers through the running system and record open decisions
Provide evidence and controls that your auditors or assessors can review, without issuing any attestation ourselves

How we support

Fixed-scope engagements agree deliverables and timelines in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer
Re-run tests and reviews when Milvus or PostgreSQL release lines change in your estate
Quotes follow from the written scope, so ask for the cost components and what recurs after handover

Milvus vs pgvector