Milvus vs Qdrant: Open Source Vector Databases Compared (2026)

Quick verdict

Short answer

Choose Milvus if you expect very large collections, want to choose between memory, disk and GPU indexes, and have the skills to run a distributed system on Kubernetes (or will use Zilliz Cloud). Choose Qdrant if your searches combine vectors with many metadata conditions, you want a single server binary that is simple to self-host, and you would like the managed option to come from the same team. Both have BM25 hybrid search and several multitenancy patterns, so the deciding factors are index flexibility versus operational simplicity and filtered search behaviour.

How we know: This comparison is research-based: licences, architecture, index types, quantization, hybrid search, filtering, multitenancy, managed offerings and pricing were checked on 7 November 2026 against Milvus and Qdrant documentation, release notes, GitHub repositories and the Zilliz and Qdrant pricing pages. We have not deployed either database, so nothing here is a measured result.

Milvus is an open source vector database under the LF AI & Data Foundation, licensed under Apache 2.0, with Zilliz as its major contributor. It runs in three modes from one API: Milvus Lite, a library installed with pip; Standalone, a single-machine server; and Distributed, a Kubernetes-native cluster that relies on object storage, etcd and a write-ahead log service (Kafka, Pulsar or Woodpecker). The 3.0 line arrived on 29 July 2026; 3.0.5 was released on 30 October 2026. The managed version is Zilliz Cloud, a separate commercial product.

Qdrant is an open source vector database server written in Rust under Apache 2.0, developed by the company Qdrant. Each point holds dense, sparse or multi-vectors plus a JSON payload. You can self-host it with Docker or Kubernetes, use Qdrant Cloud on AWS, Google Cloud or Azure, or run Qdrant-managed clusters on your own infrastructure with Hybrid Cloud. Release 1.19 (5 August 2026) added memory tiers and removed the legacy /search, /recommend and /discover endpoints in favour of /query.

Side by side

Aspect	Milvus	Qdrant
Licence and governance	Apache 2.0; LF AI & Data Foundation project, Zilliz the major contributor	Apache 2.0; developed by Qdrant (the company)
Architecture	Lite (embedded), Standalone, or Distributed on Kubernetes with object storage, etcd and a WAL service	Single Rust server; clusters with sharding and replication
Vector index types	FLAT, IVF_FLAT, IVF_SQ8, IVF_PQ, IVF_RABITQ, HNSW (SQ, PQ, PRQ), DISKANN, SCANN, AISAQ, GPU_CAGRA and GPU IVF	HNSW (filter-aware), plus sparse vector indexes
Quantization	Built into index variants (SQ8, PQ, RaBitQ, HNSW_SQ/PQ/PRQ)	Scalar, binary, product and TurboQuant (since 1.18)
Filtering	Scalar and JSON fields with INVERTED, BITMAP, STL_SORT and Trie indexes	Typed payload indexes (keyword, numeric, geo, datetime, text, uuid) feeding filter-aware HNSW edges
Hybrid search	Built-in BM25 function creates sparse vectors; multi-vector hybrid search with dense fields	Query API prefetch of dense and sparse results fused with RRF, weighted RRF or DBSF; server-side BM25
Multitenancy	By database, collection, partition or partition key (partition key scales to millions of tenants)	Payload partitioning with is_tenant, user-defined sharding, or tiered multitenancy
Embedding integration	Function module calling external providers (OpenAI, Cohere, Voyage AI, Bedrock, Vertex AI and others)	FastEmbed client library; Cloud Inference on Qdrant Cloud
Managed service	Zilliz Cloud (separate product; AUTOINDEX instead of the full index menu)	Qdrant Cloud, Hybrid Cloud and Private Cloud from the same vendor
Managed pricing transparency	Zilliz publishes serverless and dedicated starting prices	Free tier specs published; Standard unit rates only in the calculator
Main trade-off	Most index choice and scale-out design, with the most components to operate	Simpler to run and strong on filtered search, with HNSW as the only dense index

Key differences

Architecture and operations

Milvus separates storage from compute. In distributed mode, data lives in object storage (MinIO, AWS S3 or Azure Blob Storage), metadata in etcd, and the write-ahead log in Kafka, Pulsar or Woodpecker, with separate node roles that scale independently on Kubernetes. That design is built for very large collections, but it is a system of several services to deploy, monitor and upgrade. Standalone and Milvus Lite remove most of that weight for smaller workloads and use the same client API.

Qdrant is a single Rust binary. A one-node deployment is a container with a volume; a cluster adds sharding and replication across nodes. There is no external metadata store or message queue to run. In our view this makes Qdrant the easier of the two to self-host for small and medium teams, while Milvus gives more room to grow into a large, separated architecture.

Index choice versus filter-aware HNSW

Milvus documents the broadest index menu in this category: flat and IVF variants for partition-based search, HNSW with SQ, PQ and PRQ compression, DISKANN and AISAQ for disk-resident data, SCANN, and GPU indexes such as GPU_CAGRA. You pick the index and its parameters per vector field, which lets you trade recall, memory, disk and hardware cost. The flip side is more decisions to make and tune.

Qdrant uses HNSW for dense vectors and concentrates on making it work well with filters. If payload indexes exist before the graph is built, Qdrant adds filter-aware edges so that filtered searches stay accurate instead of returning too few results. Memory is managed with quantization (scalar, binary, product and TurboQuant, added in 1.18) and, since 1.19, memory tiers. The catch is ordering: create payload indexes before loading and indexing data, or you will need to rebuild the index.

# Qdrant (Python client): index the tenant field before loading vectors
client.create_payload_index(
    collection_name="docs",
    field_name="tenant_id",
    field_schema=models.KeywordIndexParams(type="keyword", is_tenant=True),
)

Hybrid search

Both support keyword plus vector retrieval without a separate search engine. Milvus has a built-in BM25 function that converts raw text into sparse vectors at insert time, so full-text and dense search can be combined in one multi-vector hybrid search request. Qdrant runs hybrid search through its Query API: it prefetches candidates from several vectors (for example BM25 sparse and dense) and fuses them with RRF, weighted RRF or DBSF. Since 1.15.2 Qdrant converts text to BM25 sparse vectors on the server, and 1.19 added per-tenant IDF statistics for BM25.

Multitenancy patterns

Milvus documents four strategies: a database per tenant, a collection per tenant, a partition per tenant, or a partition key that hashes tenants into partitions and scales to millions of tenants. The documentation notes that partition and partition-key tenancy do not support RBAC, so strong isolation needs databases or collections. Qdrant recommends one collection with a tenant payload field indexed with is_tenant for many small tenants, user-defined sharding for a few large tenants, or tiered multitenancy, which promotes large tenants to dedicated shards.

Managed options

The Milvus project itself has no managed service; Zilliz Cloud, from the major contributor, is the managed path. It offers Free, Serverless, Dedicated, Business Critical and BYOC deployments on AWS, Google Cloud and Azure, and replaces the index menu with AUTOINDEX (a customised HNSW or DiskANN depending on cluster type). Qdrant Cloud comes from the same company as the engine and offers a free-forever cluster, a usage-based Standard tier, Premium, and Hybrid Cloud for running Qdrant-managed clusters on your own infrastructure. If moving between self-hosted and managed with identical behaviour matters, check which features each managed service exposes.

Pricing and licensing

Milvus is free under Apache 2.0; you pay for the infrastructure (compute, object storage, and the WAL and metadata services in distributed mode). The managed Zilliz Cloud (zilliz.com/pricing, 7 November 2026, $ sign): a Free cluster with 5 GB storage, 2.5M vCUs a month and up to 5 collections, suspended after 7 days of inactivity; Serverless billed at $4 per million vCUs with storage charged by region; Dedicated clusters from $126 a month on Standard and $197 a month on Enterprise; Business Critical, On-demand Compute and BYOC by quote.

Qdrant is free to self-host under Apache 2.0. Qdrant Cloud (qdrant.tech/pricing, 7 November 2026): a free-forever single-node cluster with 0.5 vCPU, 1 GB RAM and 4 GB disk, no high availability, suspended after 1 week unused and deleted after 4 weeks of inactivity; Standard billed hourly on vCPU, memory and storage with a 99.5% SLA, but the page text gives no unit rates and points to a calculator; Premium with a minimum spend (amount not stated) and a 99.9% SLA; Hybrid Cloud, Private Cloud and Enterprise on request.

Pricing checked on the vendors' official pages on 7 November 2026. Prices change; confirm before buying.

Where each one leads

Milvus strengths

Broadest documented index choice, including DISKANN, SCANN and GPU indexes
Distributed architecture with storage and compute separated for very large collections
Same API from a pip-installed Lite library to a Kubernetes cluster
Vendor-neutral foundation governance under Apache 2.0
Partition-key tenancy that scales to millions of tenants

Qdrant strengths

Filter-aware HNSW and typed payload indexes keep filtered searches accurate
Single Rust server that is simple to run with Docker or Kubernetes
Hybrid Query API with RRF, weighted RRF and DBSF fusion and server-side BM25
Several quantization methods, including TurboQuant
Managed Qdrant Cloud and Hybrid Cloud from the same team that builds the engine

Limitations

Milvus limitations

Distributed mode needs object storage, etcd and a WAL service, which is real operations work
Index choice and tuning add decisions that a single-index engine avoids
Partition and partition-key tenancy do not support RBAC
The managed Zilliz Cloud uses AUTOINDEX rather than the full index menu

Qdrant limitations

HNSW is the only dense vector index; no IVF, DiskANN or GPU index options
Payload indexes must exist before indexing to get filter-aware edges
Qdrant Cloud Standard rates are not printed on the pricing page
Version 1.19 removed legacy endpoints, so older clients must migrate to /query

When to choose each

Choose Milvus if

You plan for hundreds of millions of vectors or more and want storage and compute to scale separately
You need disk-based or GPU indexes, or want to pick IVF or HNSW variants per field
Your platform team already runs Kubernetes and supporting services such as Kafka or Pulsar
You want vendor-neutral foundation governance
You want a managed path through Zilliz Cloud with published starting prices

Choose Qdrant if

Queries combine vectors with many metadata, geo or date filters
You want a database that is simple to self-host as one service
You need flexible hybrid fusion (RRF, weighted RRF, DBSF) in one query API
You serve many small tenants from one shared collection, with a route for large tenants
You want the engine and the managed cloud from the same vendor

When neither is right

You do not want to operate a vector database at all and accept a proprietary service: see Pinecone vs Weaviate.
Your vectors fit in PostgreSQL next to relational data: see pgvector vs Pinecone.
You need an in-process library rather than a server: see Chroma vs LanceDB.
You need a full-text search engine with vector search added: see Elasticsearch vs OpenSearch vector search.

Final recommendation

Bottom line

Milvus is the more direct fit for teams that need index flexibility and scale-out architecture, and have the operations capacity for a distributed system or plan to buy Zilliz Cloud. Qdrant is the more direct fit for teams whose results must respect rich filters and who value a single, easy-to-run server with a managed cloud from the same vendor. Both are Apache 2.0, so a short proof of concept with your own filters, data size and tenancy model is cheap; plan payload indexes up front on Qdrant and index types up front on Milvus.

Frequently asked questions

Are Milvus and Qdrant both open source?

Yes. Both are under the Apache License 2.0. Milvus is an LF AI & Data Foundation project with Zilliz as its major contributor; Qdrant is developed by the company Qdrant. Their managed services, Zilliz Cloud and Qdrant Cloud, are commercial.

Which has more index types?

Milvus. Its documentation lists FLAT, IVF variants, HNSW variants, DISKANN, SCANN, AISAQ and GPU indexes such as GPU_CAGRA. Qdrant uses HNSW for dense vectors, made filter-aware by payload indexes, and relies on quantization to manage memory.

Do both support BM25 hybrid search?

Yes. Milvus has a built-in BM25 function that produces sparse vectors combinable with dense search. Qdrant converts text to BM25 sparse vectors on the server (since 1.15.2) and fuses results through its Query API with RRF, weighted RRF or DBSF.

Is Zilliz Cloud the same as Milvus?

No. Zilliz Cloud is a separate commercial managed service built on Milvus by Zilliz. It uses AUTOINDEX for vector fields instead of offering every Milvus index type.

Sources

Checked November 2026.

How we research comparisons: our editorial method.