Milvus

Editor’s note: I evaluate Milvus on pricing transparency, real-world adoption signals, development momentum, openness and exit costs, and practitioner sentiment. My verdict draws on documented capabilities and published evidence, not a hands-on performance test.

Quick verdict: I recommend Milvus for teams scaling past tens of millions of vectors, for lakehouse stacks using 3.0’s External Collections, and for GPU or DiskANN index workloads. The trade-off: distributed mode means Kubernetes, etcd, object storage, and a write-ahead log before the first query, and under roughly 10 million vectors that stack is over-engineered for the job.

In this Milvus review, I’ll look at the costs, deployment choices, and search capabilities of 3.0, the July 2026 release most published advice misses.

Key Takeaways 🔍

• Milvus 3.0 went GA July 29, 2026: External Collections index Parquet, Lance, and Iceberg files in place
• Widest index menu in the category: HNSW, IVF variants, FLAT, SCANN, DiskANN, and GPU CAGRA
• 46,271 GitHub stars as of September 28, 2026; Apache 2.0, LF AI & Data governed
• Distributed operations are real work: documented rolling-upgrade failure modes, and one team reports outspending a managed service on ops within six months
• Self-hosters accept a performance ceiling: Cardinal, Zilliz’s fastest search core, stays proprietary

Pros and Cons

What I like most about Milvus is its capacity to scale. My main concerns are the operations costs:

I’ll put dollar and hour figures on those costs in the pricing section, then cover the upgrade risks below.

How Much Does Milvus Really Cost?

Milvus costs $0 in license fees under Apache 2.0. When I assess its cost, I count infrastructure and engineering time. Both vary by deployment tier:

• Milvus Lite ($0): embedded in your Python process via pip, zero infrastructure, built for prototyping
• Standalone (a VPS bill): one Docker container with persistent storage, the tier for small-to-mid production workloads
• Distributed (real money): Kubernetes plus etcd for metadata, S3 or MinIO for objects, and the Woodpecker write-ahead log that replaced the Kafka/Pulsar dependency in 2.6

For distributed Milvus pricing, one independent 2026 cost model sized a 100-million-vector cluster on AWS EKS: an r6g.xlarge Spot query node, an r6g.large Spot index node, an m6g.large on-demand coordinator (kept off Spot because it must stay stable), the EKS control plane, and about 1.2TB of S3 storage at roughly $0.02 per GB-month. Treat the figures as third-party estimates, not quotes:

Setup at 100M vectors	Monthly estimate (third party)
Self-hosted Milvus on EKS, single replica	~$370
Self-hosted Milvus on EKS, with HA second query node	~$442
Zilliz Cloud Dedicated, equivalent capacity	$600-1,200
Pinecone Pods, equivalent capacity	~$5,760

High availability is the cheapest line on that bill: the second query node adds roughly $72 a month.

My biggest concern with the infrastructure estimates is the engineering time they leave out. One operator running roughly 50 million vectors on a single instance reports about 4 hours a month of maintenance: backups, occasional restarts, and monitoring alerts that sometimes fire wrong, plus one incident in eight months that took two hours to resolve. The counter-testimony from the same forum thread is a team that spent more on operations in six months than a managed service would have cost. The same cost model puts the self-hosting break-even near $500 a month of managed spend; below that, ops hours eat the savings.

Index choice is the biggest cost lever at scale. DiskANN, which splits the index between memory and disk, was the only option that cost model found economically viable under $1,000 a month at 100 million vectors, where full in-memory HNSW is not. RaBitQ 1-bit quantization, added in 2.6, compresses indexes to roughly 1/32 of their original size at about 95% recall, which cuts the RAM a billion-vector collection needs.

Is Milvus Good Value for Money?

• Far cheaper at scale: ~$370-442 a month self-hosted covers capacity the same estimate prices near $5,760 on Pinecone and $600-1,200 on Zilliz Cloud Dedicated
• A money-loser below break-even: under roughly $500 a month of managed spend, engineering time outweighs the savings
• Free all the way down: Lite and Standalone cost nothing beyond the hardware they sit on
• Budget hours, not just dollars: even a smooth 50M-vector deployment ran 4 hours a month of maintenance

Reviewer’s Notes 📝

I’d prototype on Milvus Lite, then run Standalone in Docker until passing roughly 10 million vectors or needing high availability. I’d choose Distributed only with a platform engineer on staff who already owns Kubernetes; the etcd, object storage, and WAL stack is a job responsibility, not a side quest.

— Panoply reviewer

Getting Started With Milvus

I’d approach Milvus in stages: start with Lite, move to Standalone, and take on Distributed when the workload justifies it.

Starting with Milvus Lite

The whole install is a single pip install through the pymilvus client. Lite runs inside the Python process, persists to a local file, and needs no server, no Docker, and no cluster. I treat it as the honest on-ramp: the client API is the same one you keep at every tier, so the collection and search code from a notebook carries forward with only the connection URI changed when you outgrow it.

Standalone in Docker

Standalone is a single Docker container with persistent volumes, and it is the tier I’d recommend for most teams. It gives you a real server, real backups, and none of the distributed dependency stack. I like the option to browse collections, inspect indexes, and check segment state through the web console instead of writing client code for every look.

Picking a Consistency Level

Milvus exposes four consistency levels, settable per collection or per query, and the choice is a real workload decision:

• Strong: always reads the latest data, at a search-speed cost; use it for financial or compliance-sensitive lookups
• Bounded (the default): tolerates brief staleness; right for most recommendation-style workloads
• Session: a client immediately sees its own writes; the setting for upload-then-search flows, where a user adds a document and queries it in the next request
• Eventually: fastest, no freshness guarantee; use it when raw query speed wins

Where Distributed Gets Real

A distributed cluster is Milvus plus three stateful services: etcd for metadata, S3 or MinIO for segment storage, and the Woodpecker WAL, which runs as its own service in 3.0. Before 2.6, that slot was a Kafka or Pulsar cluster, so the stack is one system lighter than older guides describe. Kubernetes coordinates all of it, which is why the tier starts at a platform team, not a weekend.

I’d plan maintenance windows around two known rolling-upgrade failure modes. Replica rebalancing can start moving segments inside the replica still serving traffic before its replacement begins loading, taxing that replica’s CPU, memory, and I/O mid-upgrade. A QueryNode shutdown can also hang with no timeout when object storage returns errors for segment files. I wouldn’t trust a green post-upgrade readiness check on its own either; open issues describe checks reporting healthy when they are not.

One more trap: copying volume directories to a new server can restart clean while collections stay invisible, so migrate with backup tooling, not file copies.

Reviewer’s Notes 📝

I’d treat version upgrades as releases in their own right. Given the documented rebalancing and shutdown-hang cases, I’d run every rolling upgrade against a staging replica first and keep a tested restore point before touching the serving cluster.

— Panoply reviewer

Milvus 3.0: Lake-Native Changes the Deployment Math

Most Milvus advice you will find describes 2.x. Version 3.0 reached general availability on July 29, 2026, and its headline feature deletes a whole category of pipeline work.

External Collections build vector, full-text, JSON, and scalar indexes directly over data sitting in Parquet, Lance, Iceberg, or Vortex files in object storage. Nothing is copied into Milvus first. If your embeddings already live in an Iceberg table on S3, Milvus indexes them where they are, and the ETL job that used to shovel them into the database stops existing.

Under the hood, 3.0 ships a new storage engine called Loon. It is manifest-based, designed to cut read amplification for low-latency point access on object storage, and it uses Vortex, an Arrow-compatible columnar format, as the default. The LF AI & Data Foundation frames the shift plainly: index vectors where they already live instead of moving them to the index.

Adopting 2.x meant provisioning a cluster and holding the data twice, once in the lake and once in Milvus segments, with an ingestion pipeline keeping the copies in sync. With External Collections, the object store you already pay for is the storage layer, and Milvus’s job shrinks to compute and indexing. The boundary is the format list: Parquet, Lance, Iceberg, and Vortex are covered, and data anywhere else still needs an export step first.

For teams on a lakehouse stack, this addresses my strongest objection to running a separate vector database: the duplication and sync pipeline. For everyone else, 3.0 changes little today; a standalone RAG app with 5 million vectors gains nothing from lake-native indexing it is not doing. Decide on 3.0 either way, because the 2.x-era articles you are comparing against are reviewing a smaller product.

Indexes, GPU Acceleration, and Hybrid Search

The breadth of its index menu is one of my main reasons to consider Milvus at scale:

• HNSW: the graph-index default for low-latency, in-memory search
• IVF_FLAT and IVF_SQ8: cluster-based indexes; IVF_FLAT trades a little recall for speed, and IVF_SQ8 adds scalar quantization to cut memory
• FLAT: brute force, exact results, small collections only
• SCANN: Google’s quantization-heavy design for high throughput
• DiskANN: hybrid disk and memory, built for 100-million-vector-class collections that can tolerate around 100ms latency
• GPU CAGRA: the CUDA graph index added in 2.4

The CAGRA numbers come from Zilliz’s own engineering write-up, so I treat them as vendor claims: index builds 10 to 50x faster than CPU HNSW, and sub-millisecond p50 query latency when the whole index fits in GPU VRAM. That VRAM condition is the catch, and the GPU path is CUDA-only, with no Huawei Ascend support.

An independent 2026 Salt Technologies AI benchmark at 1 million vectors and 1,536 dimensions measured Milvus with GPU at 6ms p50 and 12-18ms p99, against 15-25ms CPU-only. That trails self-hosted Qdrant’s 4ms p50 but beats Pinecone Serverless (20-30ms p50, with cold-query p99 at 40-80ms) and Weaviate Cloud (50-70ms p50). Benchmarks shift with hardware and dataset, so read them as ordering, not gospel.

Hybrid search went native in 2.6 with built-in BM25, so keyword and vector retrieval run in one system instead of a Milvus cluster beside an Elasticsearch cluster. The one published throughput figure is a single comparison author’s own benchmark: 400% higher hybrid-search throughput than Elasticsearch on equivalent hardware. I’d treat it as one data point until your own workload confirms it. Pair native BM25 with the RaBitQ quantization covered in the pricing section and one cluster covers both dense and keyword retrieval at billion scale.

Milvus vs Zilliz Cloud: What the Open Source Version Holds Back

Zilliz, the company that created Milvus, sells Zilliz Cloud, and that managed service runs Cardinal, a proprietary search core that does not ship in open-source Milvus. Self-hosting means accepting a performance ceiling on the identical API surface.

What the money buys is mostly subtraction: no etcd, no MinIO, no WAL service, no Kubernetes, no rolling-upgrade maintenance windows. Backups, replication, and security hardening, which self-hosters own outright, move to Zilliz as well. Pricing, per independent price trackers:

• Serverless: roughly $0.096 per compute-unit-hour, so one CU running all month (720 CU-hours) comes to about $69
• Dedicated: listed as starting somewhere between $70 and $99 a month
• Free tier: 100 compute-unit-hours and 5GB of storage, enough to try the managed API before committing

Zilliz also announced a storage price of $0.04 per GB-month from January 2026, an 87% cut from $0.30, alongside a 25% compute price cut. Confirm current rates on the live Zilliz Cloud pricing page before budgeting.

My recommendation from the pricing section carries over: below about $500 a month of managed spend, Zilliz Cloud is usually the better buy; above it, self-hosting starts paying for its own ops. Zilliz Cloud’s own plans and features are a separate evaluation; this review covers the open-source database.

Who Actually Runs Milvus

The GitHub repository stands at 46,271 stars, 4,275 forks, and 1,422 open issues as of September 28, 2026; older articles still citing 30,000 or 44,000 stars are dating themselves.

Shopee runs Milvus for instant video recall in its recommendation systems, leaning on multi-replica mode for low-latency, high-availability retrieval. eBay uses it to power ad recommendations, matching users to sponsored listings by semantic similarity rather than keywords alone.

Beyond those two, the logo list (Salesforce, PayPal, NVIDIA, Airbnb, IBM, AT&T, Roblox, Bosch, and others), spanning search, recommendation, agentic-pipeline, and multimodal workloads, traces back largely to vendor material, so read it as reported users rather than audited deployments.

The tempering signal: PeerSpot practitioners rate Milvus 7.4 out of 10, ranking it #13 among vector databases and #10 among open source databases on that platform. They praise stability and scalability once it is running and name a steep learning curve, especially for distributed setups, as the recurring complaint. My reading is that operations, rather than search quality, account for much of the frustration.

How Does Milvus Compare to Competitors?

When I compare Milvus with alternatives, I start with how many vectors you expect to hold in two years.

• Qdrant: the lowest published latency of any purpose-built vector database (4ms p50 self-hosted in the independent Salt Technologies benchmark) and a single binary with no Kubernetes requirement. Self-hosted cost is the lowest of the group too: roughly $20-40 a month of VPS handles 10 million vectors with binary quantization. Its ecosystem at billion scale is thinner than Milvus’s, and it is my default suggestion for most RAG teams below that scale.
• Pinecone: zero-ops serverless and the fastest path from prototype to production. The cost model above estimates ~$5,760 a month for capacity a $370-442 self-hosted Milvus cluster covers, and cold queries spike to 40-80ms p99.
• Weaviate: the most mature turnkey hybrid search, built-in vectorizer modules for OpenAI and Cohere, and native MCP server support since v1.37. Dimension-based billing multiplies with replication, which makes binary quantization near-mandatory above 1 million vectors, and Weaviate Cloud ran 50-70ms p50 in the same independent benchmark.
• pgvector: the right answer up to roughly 10-50 million vectors if you already run Postgres, with joins and transactions for free. There is no DiskANN and no GPU path beyond that scale.
• Elasticsearch: the one-stop shop when you need logs, keyword search, and vectors in one system. A benchmark cited on Zilliz’s own comparison page puts Elasticsearch exact kNN at 1,600ms against Milvus’s 7ms p99; it is vendor-published, and exact kNN is brute force, so read it as a gap in approach rather than a like-for-like race.

My rule of thumb: above 100 million vectors, Milvus is the only option in this group built for the job. Below 10 million it is usually the wrong first choice, and Qdrant, pgvector, or Chroma will get you there with far less machinery.

How I Reviewed Milvus

I assessed Milvus’s deployment requirements, index options, licensing, and infrastructure costs against the alternatives covered here. I used documentation, published benchmarks, third-party cost estimates, and operator reports to weigh the trade-offs. The performance figures in this review are attributed to their sources; they are not measurements from my own deployment.

I treat GitHub activity and practitioner feedback as supporting evidence, with more weight on deployment requirements and operating costs. Vendor benchmarks and third-party estimates help frame the decision, but I would validate both against your workload before committing. Prices current as of September 2026.

Milvus Review: Should You Build Your Vector Infrastructure on Milvus?

Among the vector databases in the Panoply directory, Milvus is my pick for scale: disaggregated storage and compute built for billion-vector collections, governed by the LF AI & Data Foundation rather than a single vendor. I recommend it for teams scaling past tens of millions of vectors, for lakehouse stacks that can put 3.0’s External Collections to work, for GPU-index workloads, and for organizations that want open source with no license risk on the exit path.

I’d skip it in three cases. Under roughly 10 million vectors, Qdrant, pgvector, or Chroma deliver the same outcome with a fraction of the machinery. Without platform engineering on staff, buy Zilliz Cloud or another managed service instead of learning etcd on production traffic. And if single-digit-millisecond latency on a small deployment is the whole game, Qdrant’s benchmark numbers win it.

My recommendation is to start with Milvus Lite in a notebook. I’d move to Standalone in Docker when the prototype graduates and take on Distributed only when the vector count and the staffing both justify it.

FAQ

Is Milvus really free?

The software is, under Apache 2.0, with no seat limits or field-of-use clauses. The bill is infrastructure and engineering time: a third-party model priced a 100-million-vector AWS EKS cluster at $370-442 a month before staff hours. Milvus Lite and Standalone run on hardware you already have. Below roughly $500 a month of equivalent managed spend, the ops hours usually cost more than they save.

Do I need Kubernetes to run Milvus?

Only for the Distributed tier. Milvus Lite runs embedded in a Python process with zero infrastructure, and Standalone runs as a single Docker container that handles small-to-mid production workloads. Kubernetes, etcd, object storage, and the Woodpecker write-ahead log enter the picture only when you need horizontal scale or high availability.

What is the difference between Milvus and Zilliz Cloud?

Zilliz Cloud is the managed service from Milvus’s commercial steward, built on the same API but running Cardinal, a proprietary search core open-source Milvus does not get. It removes the etcd, MinIO, and WAL operational burden for usage-based fees. Below about $500 a month of managed spend, managed usually wins; see the Zilliz Cloud section above.

Is Milvus overkill for small projects?

Usually, yes. Under roughly 10 million vectors, the multi-service architecture adds operations without adding performance you can feel. Milvus Lite and Standalone soften this, but Chroma, Qdrant, or pgvector are simpler starting points at that scale, and Qdrant self-hosts 10 million vectors on a $20-40 VPS.

How does Milvus handle consistency?

Through four tunable levels, set per collection or per query: Strong always reads the latest data, Bounded (the default) tolerates brief staleness, Session guarantees a client sees its own writes, and Eventually maximizes speed. See Picking a Consistency Level above for which workload fits each.