Milvus

Distributed vector DB built for billion-scale workloads. Heavy, capable, China-AI-aligned.

VISIT MILVUS

Key takeaway: Reserve Milvus for workloads where separating storage from compute is the only thing that works: billions of vectors, continuous ingestion, and a platform team who already run distributed systems. Below roughly a hundred million vectors, Qdrant or Weaviate will do the same job with a fraction of the moving parts.

Quick facts

  • CategorySelf-hosted
  • EngineGo / C++
  • PricingFreemium
  • LicenseApache-2.0
  • Created2019
  • GitHub stars32.6k
  • Hybrid searchNative
  • Edge-readyNo
  • Multi-tenantNative
  • Max dimensions32,768

What it is

Milvus is a distributed vector database designed for billion-scale workloads. Cluster-mode handles horizontal scale beyond what Weaviate or Qdrant target. Heavier operationally than the alternatives. Backed by Zilliz, deployed at scale across the China AI ecosystem and increasingly in Western enterprises.

Best for

  • Genuinely massive vector workloads (1B+ vectors)
  • Enterprise deployments with dedicated platform-engineering capacity
  • Apps with multimodal data and complex similarity-search requirements

When not to pick it

Skip Milvus for any workload under 100M vectors, the operational complexity is real and Weaviate / Qdrant are simpler at that scale. Skip if your team does not have ops bandwidth for distributed-systems work.

My take

Milvus is the right answer at the very top of the scale curve. For most teams it is overkill; Weaviate or Qdrant is the better default.

A distributed system, not a database binary

Milvus splits into coordinator, query, data, and index roles, and leans on external components for metadata, message streaming, and object storage. That decomposition is exactly why it scales: you add query nodes for read throughput and index nodes for build throughput independently, and storage grows on the object store rather than on the machines. It is also exactly why it is heavy. You are operating several services and their dependencies, tuning them, and debugging them when a query slows down, which is a platform-engineering commitment rather than a deployment. There is an embedded variant for local development so you can write code without standing all of that up, but do not mistake it for a preview of production operations. If the cluster architecture is not solving a problem you actually have, it is pure overhead you pay for daily.

Index breadth and the Zilliz relationship

Milvus supports more index types than anything else in this directory, including disk-based indexes for corpora too large to hold in memory and GPU-accelerated builds, which is the practical reason it gets chosen at the top of the scale curve. That breadth is also a tuning surface: pick the wrong index and the wrong parameters and you get a slow, inaccurate system with no obvious error message, so plan for benchmarking as real scheduled work rather than an afternoon. The project is Apache licensed with Zilliz as commercial sponsor and Zilliz Cloud as the managed offering, the same open-core shape as Weaviate and Qdrant. The managed route removes most of the operational objection, and for many teams evaluating Milvus that is the honest recommendation.

Frequently asked questions

Is Milvus overkill for my project?

Probably, unless you are past a hundred million vectors or expect to be soon. The cluster architecture pays for itself at that scale and costs you engineering time at every size below it. If you are choosing between Milvus and Qdrant for a normal production RAG app, Qdrant gets you there with far less to operate and far fewer things that can fail.

Milvus or Weaviate?

Milvus for raw horizontal scale, index variety, and workloads measured in billions of vectors, given a team that can genuinely run distributed infrastructure. Weaviate for a simpler single-service deployment, built-in hybrid keyword search, and vectorizer modules. Weaviate is the better default; Milvus is what you move to when scale becomes the binding constraint.

Is Milvus open source?

Yes, under Apache-2.0, with Zilliz as the company behind it and Zilliz Cloud as the managed service. Self-hosting is genuinely free and genuinely involved, because you are running a distributed system with external dependencies for metadata, messaging, and object storage rather than a single database process on one machine.

Links

Compare Milvus side-by-side

Similar tools you should also consider

If Milvus is your pick, the next conversation is short

The 30-min call is where your vector-DB choice becomes a real RAG architecture, a chunking + reranking strategy that actually works for your corpus, and a price range you can take to your stakeholders. Describe your data shape, your query patterns, your latency budget. I tell you whether Milvus is genuinely your fit.