Milvus Review (2026): Features, Pricing & Verdict
Milvus is the vector database the last two reviews kept pointing at — the purpose-built scale engine that Pinecone and Qdrant both ceded the billions-of-vectors crown to, and it wears that crown on merit. A cloud-native, open-source vector database built to handle billions of vectors, powering some of the largest AI applications in the world, Milvus is developed by Zilliz, written in Go and C++, and distributed under the Apache 2.0 licence as a project of the LF AI & Data Foundation. The architecture is the whole point: a distributed design that separates compute and storage, horizontally scaling by independently adding query nodes for read-heavy workloads and data nodes for write-heavy ones, with stateless microservices on Kubernetes that recover quickly from failure. It refuses to make you choose one deployment shape — three models share a unified API: Lite for prototyping, Standalone for testing and small-scale production, and Distributed for large-scale production, so you scale without rewriting code — and it indexes for every hardware budget: HNSW, DiskANN, quantization and binary index types, with hardware-optimised designs for both CPU and GPU. The 2026 headline is a genuine reinvention: the v3.0 release adds lake-native data access, making the data’s primary home open formats on cloud object storage — a data lake — rather than a separate database, the “Vector Lakebase” that has given competitors Pinecone, Qdrant and Weaviate something to think about. The managed path is Zilliz Cloud, from a free tier (5GB storage, 2.5M vCUs) through Serverless, Dedicated and BYOC plans. The honest counterweight this whole series has been building toward: for anything under ~10M vectors, Milvus is overbuilt — use Pinecone or Qdrant instead. This review prices the heavyweight.
- Best for
- Billion-scale and multi-datacentre vector workloads — the largest RAG, recommendation and semantic-search systems where distributed horizontal scaling, GPU indexing and lake-native storage economics are the requirement rather than the luxury
- Platform
- Cloud-native open-source vector database: compute/storage separation, stateless microservices on Kubernetes, HNSW/DiskANN/IVF/quantization/binary indexes on CPU and GPU, Lite/Standalone/Distributed deployment on one API, v3.0 Vector Lakebase (lake-native access to S3/GCS/Azure Blob), plus Zilliz Cloud managed service (Serverless, Dedicated, BYOC) with tiered storage
- Key differentiator
- Purpose-built distributed scale — the only vector database in this run engineered from the ground up for billions of vectors across many nodes, now with a lake-native architecture that keeps data in open object-storage formats instead of a proprietary store
- Pricing
- Self-hosted free (Apache 2.0, full engine); Zilliz Cloud free tier ($0, 5GB, 2.5M vCUs/month, up to 5 collections, no card); Serverless pay-as-you-go (~$4/million vCUs, $0.04/GB/month storage); Dedicated clusters from ~$99/month; BYOC and Business Critical via sales
- Vendor
- Zilliz — Redwood City, California; the company that created Milvus and operates Zilliz Cloud, the fully managed service built on it
What Is Milvus?
Milvus is what a vector database looks like when the design brief is “billions of vectors, many machines, no rewrites” rather than “make it effortless” or “make it cheap.” First released in October 2019 and developed by Zilliz, it has become the world’s most popular open-source vector database, trusted by more than 10,000 organisations, with 45,000-plus GitHub stars and sub-10ms latency at billion-vector scale — the adoption base that makes it the category’s de facto reference for scale. The engineering that earns that position is the compute/storage separation this series praised in Pinecone’s serverless and Qdrant’s resource model, but taken to its distributed conclusion: Milvus horizontally scales and adapts to diverse traffic patterns, achieving optimal performance by independently increasing query nodes for read-heavy workloads and data nodes for write-heavy ones; the stateless microservices on Kubernetes allow quick recovery from failure, and replica support enhances fault tolerance and throughput by loading data segments on multiple query nodes. The internal division of labour reads like a distributed-systems textbook — coordinators orchestrate load balancing and data, query and index management, while stateless proxies handle external requests, perform verifications and balance load — and it is precisely this separation-of-concerns that lets Milvus keep answering queries while nodes fail, rebalance, or scale, at counts where a single-node engine would have surrendered. On indexing, Milvus is the category’s broadest toolbox: HNSW, DiskANN, quantization and binary index types with hardware-optimised designs for both CPU and GPU, ensuring fast retrieval with high recall across use cases — DiskANN in particular is the answer to the memory-cost problem Qdrant solves with quantization, serving billion-vector indexes from SSD rather than demanding they all fit in RAM, and GPU acceleration is a genuine differentiator no other tool in this run matches natively. The deployment story removes the usual prototype-to-production cliff: Lite for prototyping, Standalone for testing and small-scale production, and Distributed for large-scale production, all on a unified API — enabling seamless scaling without code rewrites, which means the query you write against Milvus Lite on your laptop is the query that runs against a distributed cluster serving billions. The 2026 reinvention is the most significant architectural news in this vector run: Zilliz’s v3.0 update adds lake-native data access and a more expressive retrieval engine, where the data’s primary home is open formats on cloud object storage rather than loaded into a separate database — deployable on Kubernetes or Docker including air-gapped environments, supporting S3-compatible object storage, Google Cloud Storage and Azure Blob Storage, with Python, Go and Node.js SDKs at release and Java to follow. This “Vector Lakebase” reframes what a vector database is: not a silo your embeddings are copied into, but a query engine that reads the data lake you already have — and it is why, per the field, Zilliz has given competitors Pinecone, Qdrant and Weaviate something to think about. Zilliz’s market position is unambiguous: based in Redwood City, California, it competes with fellow specialists such as Pinecone, Qdrant and Redis, as well as broader-based providers including AWS, Google Cloud and Oracle that have added vector capabilities. Within our Model Providers & AI Infrastructure category, Milvus is where the vector run reaches its ceiling of scale — the engine the convenient and the affordable both defer to when the vector count crosses into the billions.
Core Features
Distributed by design: compute/storage separation at billion-vector scale
Milvus’s distributed architecture deserves treatment as the feature, because it is the one capability the rest of this vector run explicitly cannot match — and understanding it explains both why Milvus wins at scale and why it is the wrong tool below it. The foundation is the same compute/storage separation this series has praised twice, but where Pinecone hides it behind serverless and Qdrant expresses it as a single sizeable node, Milvus makes it a genuinely distributed, independently-scaling system: query nodes scale for read-heavy workloads and data nodes scale for write-heavy ones, independently, so a recommendation engine drowning in reads and an ingestion pipeline drowning in writes each get exactly the capacity they need without over-provisioning the other. The stateless-microservices design is what converts that into production reliability: on Kubernetes, stateless services recover quickly from failure and replica support enhances fault tolerance and throughput by loading data segments across multiple query nodes — the multi-datacentre, high-availability posture that the largest deployments require and that a single-node engine, however fast, structurally cannot offer. The coordinator/proxy split completes the picture: coordinators handle load balancing and the management of data, queries and indexes, while stateless proxies manage connections, verifications and load balancing for external requests, a separation that lets the system rebalance and scale its internals transparently while queries keep flowing. The payoff is measurable — sub-10ms latency at billion-vector scale — and it is the number that defines Milvus’s territory: not the single-digit-millisecond retrieval on a 10M-vector node that Qdrant delivers on commodity hardware, but that latency held across a distributed index of billions, which is a categorically harder engineering problem and the one Milvus was built to solve. The honest framing this review carries from the Qdrant verdict, which named Milvus its extreme-scale successor: below the threshold where you actually have billions of vectors or genuine multi-node availability requirements, this architecture is pure overhead — the field’s blunt verdict is that Milvus is overbuilt for 1M vectors, and Pinecone or Qdrant are the right answer there — because distributed coordination, Kubernetes operation and multi-node infrastructure cost real complexity that a small workload never recoups. But at the top of the scale curve, where that complexity buys horizontal scaling, independent read/write elasticity and datacentre-spanning resilience, Milvus is the only tool in this run that answers the requirement — which is exactly why the two reviews before it handed the crown over rather than contesting it.
v3.0 Vector Lakebase: lake-native data and the tiered-storage economics
The v3.0 release is the freshest and most strategically significant development in this entire vector run, because it changes not how fast Milvus searches but what a vector database fundamentally is. The core shift: lake-native access means the data’s primary home is open formats on cloud object storage — a data lake — not loaded into a separate database, so instead of the universal pattern this series has assumed throughout (embeddings generated, then copied into a vector store that owns them), Milvus v3.0 queries the open-format data where it already lives. The consequence for adoption cost is the part that reframes procurement: as long as your data already sits in one of the open table formats Milvus can read, adopting it isn’t a migration project — which opens it up to teams that could never justify the migration in the first place, a genuinely different value proposition from every rival whose onboarding is, definitionally, a data-copy exercise. The deployment reach matches the ambition — Kubernetes or Docker, including air-gapped environments, with S3-compatible object storage, Google Cloud Storage and Azure Blob Storage support, and Python, Go and Node.js SDKs available at release — and the air-gapped capability quietly answers the sovereignty requirement this series covered in the Aleph Alpha and Qdrant Hybrid Cloud reviews: the fully disconnected deployment that managed control planes structurally cannot offer. The economics arrived in stages across 2026 and they are dramatic. The January GA of Milvus 2.6.x on Zilliz Cloud introduced a cloud-native multi-layer storage architecture that automatically places data across memory, local SSD and object storage based on access patterns — hot data stays fast, cold data stays cheap — delivering over 90% cache hit rates in production and up to 87% lower storage costs with reduced compute overhead, the same hot/cold tiering discipline every mature database workload eventually adopts, here built into the platform. That release also broadened the data model well beyond vectors: native support for spatial data, timezone-aware timestamps, INT8 vectors and nested structures, alongside improved multilingual tokenization and phrase search — enabling complex, global AI applications without external systems, and an Index Build Level control that automatically balances recall, performance and storage efficiency. Read together, v2.6 and v3.0 describe a deliberate trajectory: Milvus is converting from “the vector database that scales furthest” into “the retrieval engine that sits on your data lake and serves everything from real-time vector search to batch analytics” — the Vector Lakebase pitch, and the reason the field says it has given the rest of the category something to think about. The counterweight this review must register: v3.0 is new (the beta shipped mid-2026), the lake-native model rewards teams who already run open table formats and offers less to those who don’t, and the more capabilities Milvus absorbs, the more the operational-complexity objection compounds — this is the most powerful vector engine in the run, and also the one that asks the most of the team running it.
Deployment spectrum, index breadth and the operational-complexity trade
Milvus’s third pillar is optionality — of deployment, of index, of managed-versus-owned — and the honest reading of it is that the breadth is both the platform’s greatest strength and the source of its defining weakness. The deployment spectrum is the widest in this run: Milvus Lite for prototyping runs as a Python-embedded local instance with zero setup, Standalone serves testing and small-scale production, and Distributed handles large-scale production — all on one unified API, so the same code path spans a laptop file and a billion-vector cluster; and the managed alternative removes the operational burden entirely — Milvus is available as a fully managed service on Zilliz Cloud, with Serverless, Dedicated and BYOC options, the last running the engine inside the customer’s own cloud account for the sovereignty-bound. The index breadth is the category’s most complete: HNSW for balanced in-memory performance, DiskANN for serving huge indexes from SSD, plus quantization and binary index types, all with hardware-optimised CPU and GPU designs — DiskANN is the strategic differentiator here, because it attacks the RAM-cost problem from the opposite direction to Qdrant’s quantization (keep the index on fast disk rather than compressing it into memory), and for billion-vector workloads where even 32x compression leaves too much to hold in RAM, disk-based indexing is the answer; GPU acceleration, meanwhile, is a capability no pure-CPU rival in this run offers natively, and for the largest indexing and search workloads it is a genuine throughput multiplier. Now the operational-complexity trade this review has flagged at every turn, stated plainly. Distributed Milvus is a real distributed system: it wants Kubernetes, it has multiple node types and coordinators to understand and size, and its power is inseparable from the infrastructure sophistication it demands — which is why the field’s verdict is not that Milvus is worse than Pinecone or Qdrant but that it is overbuilt for the workloads most teams actually have, with Pinecone or Qdrant the right answer under a few million vectors. The mitigations are real and worth knowing: Milvus Lite makes the on-ramp genuinely trivial for prototyping; Standalone is a single-container deployment that avoids distributed complexity for small production; and Zilliz Cloud exists precisely so that teams who need Milvus’s scale but not its operational burden can rent the engine rather than run it — the same convenience-versus-control trade this series has traced across the whole category, here resolved in the customer’s favour by simply offering both ends. The synthesis: Milvus hands you more capability than any other vector database in this run — distributed scale, GPU indexing, disk-based billions, lake-native storage, the broadest index toolbox — and asks, in return, either the infrastructure sophistication to run it or the Zilliz Cloud bill to have it run for you; for the workloads that need what it offers, that is a fair trade, and for the workloads that don’t, the two reviews before this one exist for a reason.
Scored Categories
Pricing
| Tier / item | Price | Notes |
|---|---|---|
| Self-hosted (open source) | Free — Apache 2.0 | Full engine, no gated features; the open-source version is completely free — you provide the infrastructure and operations |
| Zilliz Cloud — Free Tier | Free, no card | 5GB storage, 2.5M vCUs/month, up to 5 collections — genuinely sufficient for prototyping and small workloads for months |
| Zilliz Cloud — Serverless (PAYG) | Pay-as-you-go | ~$4 per million vCUs plus $0.04/GB/month storage; scales automatically, you pay only for usage — the small-to-mid managed default |
| Zilliz Cloud — Dedicated | From ~$99/month | Dedicated clusters start around $99/month; CU-based (a CU is roughly 1 vCPU + 4GB RAM), PAYG or contract, for guaranteed production performance |
| Storage (all clusters, 2026) | $0.04 / GB / month | Cut 87% from $0.30 to $0.04/GB/month as of January 2026, standardised across AWS, Azure and Google Cloud |
| BYOC & Business Critical | Via sales | Bring Your Own Cloud runs the engine in your own account; enterprise reliability, isolation and support tiers negotiated |
| The scale-fit rule | ~10M-vector threshold | Below a few million vectors Milvus is overbuilt — Pinecone or Qdrant win; the engine earns its cost at eight-plus figures |
Strengths
- Purpose-built distributed scale — billions of vectors, sub-10ms latency, independent read/write elasticity
- The category’s broadest index toolbox: HNSW, DiskANN, quantization and binary, on CPU and GPU
- Native GPU acceleration no pure-CPU rival in this run offers
- v3.0 Vector Lakebase: lake-native access to open object-storage formats, adoption without migration
- Tiered storage cuts storage cost up to 87% at 90%+ cache hit rates
- Apache 2.0 under the LF AI & Data Foundation — self-host anywhere, air-gapped included
- Unified API from Milvus Lite on a laptop to a distributed cluster — no rewrite to scale
- The category’s largest adoption base: 45k+ stars, 10,000+ organisations, mature Zilliz Cloud managed path
Weaknesses
- Overbuilt below ~10M vectors — Pinecone or Qdrant are cheaper and simpler there
- Distributed self-hosting demands Kubernetes and real infrastructure sophistication
- The breadth of node types and coordinators is a genuine learning curve
- v3.0 lake-native model rewards teams already on open table formats; offers less to those who aren’t
- Zilliz Cloud’s CU-based billing is less intuitive than flat resource pricing
- The more capabilities it absorbs, the heavier the operational-complexity objection
- Managed small-scale value trails the serverless incumbent’s scale-to-zero
- v3.0 is new — the lake-native architecture and its tooling are still maturing
Verdict: 8.2 / 10 — The Scale Champion
Milvus earns an 8.2 as the vector database the rest of this run defers to — the purpose-built distributed engine that Pinecone’s convenience and Qdrant’s economics both handed the billions-of-vectors crown to, because neither was built to contest it. The architecture is the achievement: genuine compute/storage separation across independently-scaling query and data nodes, stateless microservices that survive failure, the broadest index toolbox in the category with DiskANN and native GPU acceleration no rival here matches, and sub-10ms latency held across billion-vector indexes — a categorically harder problem than fast search on a single node, and the one Milvus was engineered to solve. The 2026 reinvention deepens the case: v3.0’s lake-native Vector Lakebase reframes the product from a silo your embeddings are copied into to a retrieval engine that reads the data lake you already have, and the tiered-storage economics (up to 87% lower storage cost at 90%+ cache hit rates) answer the bill objection the scale it targets would otherwise raise. The deductions are the mirror image of the strengths, and they are real: below roughly ten million vectors this engine is overbuilt, its distributed mode demands Kubernetes fluency and infrastructure sophistication that a small workload never recoups, its CU-based managed billing is less legible than a flat cluster, and every capability it absorbs compounds the operational weight. The buying logic is the clearest in this vector run precisely because the tool is the most specialised: if your requirement is genuinely billions of vectors, multi-datacentre availability, GPU-scale indexing or a lake-native architecture over data you already hold in open formats, Milvus is the answer and arguably the only one — start on the free tier, let Zilliz Cloud absorb the operational burden until scale or sovereignty forces self-hosting, and configure the tiered storage before you size. If your scale is smaller, the honest answer is the one the field states plainly and this review endorses: you are overbuying, and Pinecone or Qdrant will serve you better and cheaper. Pinecone made vector search effortless and Qdrant made it affordable — Milvus makes it limitless, and for the workloads that actually reach that limit, nothing else in the category will do.
Frequently Asked Questions
Milvus vs Pinecone vs Qdrant — which vector database should I actually choose?
This vector run has reviewed all three, and the honest answer is that they occupy distinct territories rather than competing head-to-head — the choice falls out of your scale, your operational appetite and your cost sensitivity, not a feature checklist. Start with scale, because it is the cleanest divider: below a few million vectors, Milvus is overbuilt, and the field’s blunt verdict is to use Pinecone or Qdrant instead — the distributed architecture that is Milvus’s whole point is pure overhead at small scale, so this threshold alone eliminates it for most teams. Between the two smaller-scale options, the divider is cost model and operational appetite: Pinecone’s serverless is the shortest path to production with zero operations and genuine scale-to-zero economics, ideal when engineering time is your scarcest resource and your workload is under ~10M vectors or bursty; Qdrant’s flat resource pricing with zero per-query and per-write billing wins decisively at sustained scale above ~5M vectors and for write-heavy agent workloads, at the price of doing your own quantization and sizing. Milvus enters when the numbers get genuinely large: billion-vector scale with sub-10ms latency, multi-datacentre high availability, GPU-scale indexing, or the v3.0 lake-native case where your data already lives in open object-storage formats and you want to query it in place rather than migrate it — requirements that Pinecone and Qdrant, by their own reviews’ admission, cede to it. The operational dimension cuts across all three: Pinecone asks nothing (fully managed, no tuning), Qdrant asks for quantization and sizing literacy, and self-hosted Milvus asks the most — Kubernetes, multiple node types, distributed coordination — though Zilliz Cloud neutralises that by offering Milvus’s scale as a managed service. The decision rule that settles most cases: if you have billions of vectors or hard multi-node availability needs, Milvus (managed on Zilliz Cloud unless you have the infrastructure team to self-host); if you have sustained mid-to-large scale or write-heavy agents and want the best unit economics, Qdrant; if you want the fastest path to production with zero operations at small-to-mid scale, Pinecone; and if you are genuinely unsure, prototype on whichever offers the easiest on-ramp — all three have free tiers — while keeping your embeddings and metadata portable, because the scale that would push you toward Milvus tends to announce itself well before it arrives.
What is the Milvus v3.0 “Vector Lakebase,” and does it matter for my use case?
The Vector Lakebase is the most consequential architectural shift in this vector run, and whether it matters to you turns on one question: where does your data already live? The core change: v3.0 adds lake-native data access, meaning the data’s primary home is open formats on cloud object storage — a data lake — rather than loaded into a separate database, which inverts the pattern every other vector database in this series assumes. Conventionally, embeddings are generated and then copied into a vector store that owns them — a migration, an ingestion pipeline, a second copy of your data to keep in sync; the Vector Lakebase instead queries the open-format data where it already sits, so as long as your data is in one of the open table formats Milvus can read, adopting it isn’t a migration project at all — which opens it to teams that could never justify the migration in the first place. Who this matters for, concretely: organisations that already run a data lake on S3-compatible storage, Google Cloud Storage or Azure Blob Storage in open table formats gain the ability to add billion-scale vector search over that data without duplicating it, which removes both the migration cost and the synchronisation burden — a genuinely different proposition from every rival whose onboarding is definitionally a data-copy exercise. It also broadens what one system can do: Zilliz Cloud builds on the Milvus core to deliver a Vector Lakebase spanning real-time serving, interactive discovery, batch analytics and AI data operations, collapsing what used to be separate systems (a vector store for serving, a warehouse for analytics) into one engine over shared storage. Who it matters less for: teams whose data doesn’t live in open table formats, or whose scale doesn’t justify Milvus in the first place, gain little from lake-native access and would be adopting operational complexity for a capability they can’t exploit — for them, the conventional copy-into-a-store model of Pinecone or Qdrant is simpler and sufficient. The honest caveats: v3.0 is new — the beta shipped in mid-2026 with Python, Go and Node.js SDKs and Java to follow — so the tooling and ecosystem around the lake-native model are still maturing, and the “isn’t a migration” promise holds only to the degree your data genuinely already sits in the formats Milvus reads; teams not already on open table formats face the same copy-in cost as any other vector database. The practical guidance: if you run a modern data lake at scale and want vector search over it without a second copy, the Vector Lakebase is a materially new option worth piloting; if you don’t, evaluate Milvus on its distributed-scale merits and treat lake-native access as a bonus you may grow into rather than the reason to adopt.
Is Milvus hard to run, and when should I use Zilliz Cloud instead of self-hosting?
Milvus’s operational difficulty is real but tiered — it ranges from trivial to genuinely demanding depending on which deployment you pick — and the Zilliz Cloud decision is fundamentally the convenience-versus-control trade this whole series has traced, resolved by simply offering both ends. The difficulty spectrum, honestly: at the easy end, Milvus Lite runs as a Python-embedded local instance with zero setup for prototyping, and the standalone deployment is a single container that avoids distributed complexity for small production — neither is hard. The difficulty lives in Distributed mode, which is a real distributed system: it runs on Kubernetes with multiple node types (query nodes, data nodes), coordinators for orchestration and stateless proxies, each of which must be understood, sized and monitored, and operating that reliably at scale demands genuine infrastructure and Kubernetes expertise — which is precisely why the field’s verdict is that Milvus is overbuilt for workloads that don’t need it: the operational cost is inseparable from the distributed power. This is where Zilliz Cloud earns its place. The managed service — available with Serverless, Dedicated and BYOC options — runs the Milvus engine for you, absorbing exactly the operational burden that makes self-hosted Distributed demanding, so you get billion-scale vector search without staffing a distributed-systems team to keep it healthy. The decision rule: choose Zilliz Cloud when your requirement is Milvus’s scale but not the desire to operate infrastructure — which describes the large majority of teams that need billion-vector search, because the ones with the infrastructure sophistication to run Distributed Milvus well are a minority, and even many of those find the managed bill cheaper than the engineering time; the free tier (5GB, 2.5M vCUs, no card) lets you validate the fit before spending anything, and Serverless scales the managed path from there. Choose self-hosting when you have genuine reasons the managed service can’t satisfy: strict sovereignty or air-gapped requirements (though BYOC runs the engine in your own account and covers most residency needs), deep customisation of the engine internals, cost optimisation at a scale where managed margins compound into real money and you have the team to capture the savings, or a philosophical requirement for full operational independence that only running open-source software you control satisfies. The framing that settles it: Milvus’s difficulty is a function of deployment choice, not the product — Lite and Standalone are easy, Distributed is hard, and Zilliz Cloud exists so that needing Milvus’s scale doesn’t force you to also want its operational complexity; most teams should start managed and self-host only when a concrete requirement, not a preference, demands it.