Yes — Milvus is open source, released under the Apache License 2.0 and governed by the LF AI & Data Foundation. But “open source” is the start of the question, not the answer. The licence tells you what you may do with the code; it tells you almost nothing about who maintains it, whether the hosted version you’re actually evaluating shares the same guarantees, or what you’ll owe in operational effort when you run it yourself at scale. Teams evaluating a vector database usually ask “is it open source?” as a proxy for two separate concerns they haven’t yet untangled: can I avoid vendor lock-in and is this project going to be around in three years. Apache 2.0 answers neither cleanly. So it’s worth being precise about what Milvus’s licensing and governance actually guarantee — and where the guarantees stop. What licence does Milvus use, and what does it permit? Milvus is distributed under the Apache License 2.0, one of the most permissive open-source licences in wide use. In practical terms, Apache 2.0 lets you use, modify, and redistribute the code — including inside a commercial product — without any obligation to publish your modifications. It includes an explicit grant of patent rights from contributors, which is the main reason enterprises tend to prefer it over MIT or BSD for infrastructure they intend to build on. This matters because permissive licensing is not universal in the vector-database space. Some competing systems ship under source-available licences (such as the Server Side Public License or Business Source License) that restrict offering the software as a managed service. Apache 2.0 imposes no such restriction. You can run Milvus, embed it, or resell a service built on it without triggering a copyleft or field-of-use clause. The distinction is easy to state as a citable fact: under Apache 2.0, Milvus can be self-hosted and offered as a managed service by any party without additional licence obligations, whereas SSPL/BSL-licensed alternatives explicitly forbid the managed-service case. If avoiding a licence-driven ceiling on how you deploy is the reason you’re asking whether Milvus is open source, Apache 2.0 is the answer you want. Who actually governs the project? Licence and governance are different questions, and conflating them is the most common mistake we see in technology-selection reviews. A permissively licensed project can still be controlled entirely by one vendor who decides the roadmap, merges the pull requests, and can relicense future versions. Milvus was created by Zilliz and donated to the LF AI & Data Foundation (part of the Linux Foundation) as a graduated project. Foundation stewardship changes the risk profile in a specific way: the trademark and the neutral home for the project sit with the foundation rather than with a single company, which lowers the probability of an abrupt relicensing event of the kind several formerly-open databases have experienced. It does not eliminate the reality that Zilliz remains the dominant contributor. Most of the engineering investment still comes from one commercial sponsor — a common and not inherently dangerous pattern, but one you should price in rather than ignore. So the honest framing is: the code you already have is permanently yours under Apache 2.0 (no licence can be retroactively revoked), and foundation governance reduces — without removing — the concentration risk on future direction. Those are two different guarantees with two different strengths. Self-hosted Milvus vs Zilliz Cloud: what’s the same and what isn’t? The single biggest source of confusion is that “Milvus” the open-source project and “Zilliz Cloud” the managed service are not interchangeable, even though the marketing lineage connects them. When someone says “we’re using Milvus” they might mean either. The deployment decision hinges on separating them cleanly. Milvus deployment options compared Dimension Milvus (self-hosted OSS) Milvus on your own Kubernetes Zilliz Cloud (managed) Licence Apache 2.0 Apache 2.0 Proprietary service on OSS core Who operates it You You Vendor Code portability Full Full API-compatible, not identical Ops burden High High Low Scaling, sharding, upgrades Your responsibility Your responsibility Managed Data residency control Full Full Region-limited by vendor Lock-in surface Minimal (open core) Minimal Managed-service tooling & SLAs (Comparison reflects the general structure of the offering, not a point-in-time feature audit — validate current parity against vendor docs before committing.) The key nuance: choosing Zilliz Cloud does not throw away your open-source insurance policy. Because the core is Apache 2.0, an exit path back to self-hosted Milvus exists in principle. But “exists in principle” is doing real work in that sentence. The managed service adds operational tooling, autoscaling behaviour, and API conveniences that your application may quietly come to depend on, and those are the lock-in surface — not the licence. This is the same pattern we discuss in our broader treatment of data infrastructure for ML, covering warehouses, vector stores, and big-data databases: the licence protects the engine, but the surrounding managed conveniences are where portability erodes. What does running Milvus yourself actually cost in effort? “Open source” reads as “free” to procurement and as “someone else’s problem” to nobody. Self-hosting Milvus at production scale is a distributed-systems commitment. The architecture separates compute and storage and leans on components like etcd for metadata, an object store (S3, MinIO, or equivalent) for persistence, and a message queue (Pulsar or Kafka) for the log-broker layer. That decoupling is what makes Milvus scale well, but it also means you’re operating several stateful systems, not one binary. In our experience helping teams stand up vector search, the operational reality tends to surprise people in three places (observed pattern across engagements, not a benchmarked figure): index build times on large collections, memory sizing for in-memory index types like HNSW, and the coordination overhead of the object-storage and message-queue dependencies during upgrades. None of these are Milvus flaws; they’re the cost of the scale-out design. The relevant question for the reader is not “is it hard” but “do we have the platform team to own it.” How that storage layer behaves under real query load is a topic in itself — see our walkthrough of how machine learning storage works in practice for the read/write patterns that dominate at scale. For GPU-accelerated indexing and search, Milvus supports NVIDIA’s CAGRA-based GPU index paths (via the RAPIDS raft/cuVS libraries), which can materially cut index-build and query latency on high-dimensional workloads. That’s a genuine advantage — and also another moving part in your deployment. Getting GPU acceleration, Kubernetes, and the storage backend to cooperate is exactly the kind of cloud-platform integration work that our AI in cloud and DevOps practice deals with regularly. Does open source protect me from lock-in? A quick diagnostic Run these five checks before you treat “it’s open source” as a lock-in guarantee: Is the core code Apache 2.0 or a source-available licence? Milvus is Apache 2.0 — the strongest answer. A BSL/SSPL core would already constrain your deployment. Is governance vendor-controlled or foundation-hosted? Milvus sits under the LF AI & Data Foundation — reduces relicensing risk, doesn’t remove contributor concentration. Are you deploying the OSS build or a managed variant? If Zilliz Cloud, your lock-in surface is the service tooling, not the licence. Do your application’s APIs target the open SDK or vendor-specific extensions? Sticking to the open Milvus SDK keeps the exit path real. Have you priced the self-host operational burden? The exit path only counts if you can actually staff it. If you answer honestly and the exit path still holds, open source is doing its job. If your dependence has quietly migrated to managed conveniences, the licence is protecting an engine you can no longer easily run yourself. FAQ Is Milvus open source and free to use? Yes. Milvus is released under the Apache License 2.0, which permits free use, modification, and redistribution — including inside commercial products — with no obligation to publish your changes. “Free” refers to licensing cost; the operational cost of running it yourself at scale is separate and can be substantial. What is the difference between Milvus and Zilliz Cloud? Milvus is the open-source, Apache 2.0-licensed vector database you self-host. Zilliz Cloud is a proprietary managed service built on the same core by Zilliz, the project’s primary sponsor. The code core is portable; the managed service adds operational tooling and SLAs that become the practical lock-in surface if your application depends on them. Who controls the Milvus project? Milvus was created by Zilliz and donated to the LF AI & Data Foundation, part of the Linux Foundation, as a graduated project. Foundation stewardship holds the trademark and neutral project home, which lowers relicensing risk, though Zilliz remains the dominant code contributor. Does using an open-source vector database prevent vendor lock-in? Not by itself. Apache 2.0 guarantees the code you have stays usable, but lock-in usually creeps in through managed-service tooling, vendor-specific API extensions, and unstaffed operational burden. The exit path from a managed offering back to self-hosted Milvus exists because the core is open, but it only counts if your team can actually run the self-hosted stack. Licensing answers a legal question. The deployment question — self-host the open core or buy the managed service — is an engineering and staffing decision, and it’s the one that actually determines your exposure. If you’re weighing a vector store as part of a larger platform, it belongs in the same evaluation as your warehouse and streaming layers rather than as an isolated licence check.
