Yes, Milvus is open-source — released under the Apache 2.0 licence. That answer settles the software line item and nothing else. The GPUs that build the index and run the vector search are still yours to provision, size, and pay for, and that is where the real cost of a self-hosted deployment lives. This is worth stating plainly because the licence question tends to close a procurement conversation prematurely. A team evaluating a vector database for a retrieval-augmented generation (RAG) system reads “open-source,” concludes the infrastructure decision is settled, and moves on to sizing GPU capacity for the index they have not yet measured. The licence removed a cost. It did not remove the GPU underneath it. Free software running on under-filled GPUs is not a saving — it is a hidden cost wearing a licence badge. What “open-source” actually covers — and what it doesn’t Milvus is a genuine open-source project. The core database, the query nodes, the index engines, and the client SDKs are all Apache 2.0. You can clone it, run it on your own hardware, modify it, and ship it inside your own product without paying anyone. That is the whole of what the licence gives you. What the licence does not cover is the operational cost of running it at scale. There are two distinct things people conflate here: Milvus (open-source) — the software you self-host and operate yourself. Free to use; you own the hardware, the ops, and the tuning. Zilliz Cloud (managed) — the commercial, fully-managed offering from the company behind Milvus. You pay a service fee, and someone else owns the hardware and the tuning. The trade is the usual one for any open-source-versus-managed decision. Self-hosting removes the licence and service fee but hands you the infrastructure bill and the responsibility to size it correctly. Managed hosting folds both into a monthly figure. Neither is cheaper in the abstract — the answer depends entirely on how well you utilise the hardware you provision, and that is a measurement, not a licence term. Does Milvus use the GPU? It can, and this is the part that turns a licensing question into a hardware one. Milvus supports GPU-accelerated indexing and search through NVIDIA’s RAFT / cuVS libraries, exposed as GPU index types (GPU_IVF_FLAT, GPU_IVF_PQ, GPU_CAGRA). Two operations can be offloaded to the GPU: Index build — constructing the approximate-nearest-neighbour (ANN) structure over your vectors. On large collections this is compute-heavy and benefits from GPU parallelism. Vector search — the query-time similarity computation, where GPUs can serve high query-per-second (QPS) workloads that would saturate a CPU-only deployment. The moment you enable a GPU index, Milvus stops being purely a software decision. It becomes an AI workload with the same utilisation characteristics as any other GPU-bound pipeline — subject to the same idle-core, under-filled-batch, and memory-bandwidth problems that afflict inference and training. The vector database inherits every GPU utilisation pathology, and the free licence provides no protection against any of them. Where the real cost shows up Here is the mechanism the “open-source, so free” reading misses. When you self-host Milvus on GPUs, the meaningful cost metric is not cost per provisioned GPU — it is cost per useful vector operation. Those two numbers diverge exactly to the degree that your GPUs sit idle. Two utilisation gaps are common in vector-database workloads (this is an observed pattern across GPU-fed data pipelines we have profiled, not a published benchmark rate): I/O-bound ingest leaving cores idle. Index build over a large collection spends significant time reading vectors from storage and moving them across PCIe before the GPU has anything to compute on. During those windows the GPU cores are idle while you pay for them by the hour. The bottleneck is the data feed, not the compute — a pattern that shows up any time storage and interconnect can’t keep the accelerator fed. Small batches leaving memory bandwidth unused. Vector search at low or bursty query volumes issues small batches to the GPU. At small batch sizes, HBM memory bandwidth — the resource you are actually paying a premium for — goes largely unused because there isn’t enough work in flight to saturate it. The GPU reports “busy” in coarse utilisation counters while doing a fraction of the throughput it is capable of. Both gaps translate directly into TCO per useful FLOP. A GPU that is provisioned but idle during ingest, or busy-but-starved during low-QPS search, produces the same monthly invoice as one running flat-out — and the licence being free changes none of that arithmetic. A worked comparison: two ways to read the same deployment Consider a self-hosted Milvus deployment on a single GPU instance, sized for a projected peak query load. Assume the instance costs a fixed amount per month and the workload is bursty — heavy nightly re-index, light daytime queries. The illustrative figures below are for reasoning about which number to track, not a benchmark of any specific instance. Reading What it measures What it hides “Milvus is free” Software licence cost = $0 The entire GPU line item Cost per provisioned GPU Monthly instance cost, flat Whether the GPU did any useful work Cost per useful vector op Instance cost ÷ (useful index builds + served queries) Nothing — this is the number that moves when you fix utilisation The first row is true and irrelevant to sizing. The second row is what most procurement spreadsheets track, and it is blind to idle time. Only the third row tells you whether provisioning more capacity or better utilising existing capacity is the right move. This is the same cost-per-useful-work framing that separates a defensible cloud spend from an inflated one across any GPU workload where the bill scales with provisioned capacity, not delivered throughput. How do I profile GPU utilisation for a Milvus workload before sizing? You measure before you provision. The naive path — estimate peak QPS, provision a GPU class that “should” handle it, deploy — is exactly how idle capacity gets baked into a monthly bill. The correct path treats the Milvus GPU deployment as a profiling target first. A practical diagnostic sequence: Separate the two phases. Profile index build and query serving independently. They have opposite bottleneck signatures — build tends to be ingest/I/O-bound, search tends to be batch-size/bandwidth-bound — and averaging them together hides both. Watch achieved memory bandwidth, not the utilisation percentage. Coarse GPU utilisation counters report a core as “busy” even when it is stalled waiting on memory. For vector search, the honest signal is achieved HBM bandwidth relative to the device spec. Tools built on the three pillars of observability applied to GPU utilisation surface this far better than a single dashboard gauge. Measure at realistic batch sizes and query concurrency. A synthetic all-at-once benchmark saturates the GPU and tells you nothing about the small-batch daytime reality. Profile the actual query distribution. Compute cost per useful operation, not per hour. Divide the instance cost by the useful work delivered under realistic load. That single figure resolves the “provision more versus use what we have” question directly. The ML observability tooling that turns utilisation data into cloud decisions exists precisely to close the gap between “the GPU looks busy” and “the GPU is doing useful work.” For a vector store, that gap is often the difference between renting a second instance and never needing one. Should I provision more GPU capacity, or measure the fleet I have? Measure first. This is the decision the licence question quietly pre-empts, and getting it wrong is expensive in both directions — over-provision and you pay for idle silicon; under-provision without profiling and you can’t tell whether the ceiling is real or an artefact of small-batch starvation. The reframe is straightforward: a free database does not justify skipping the hardware measurement any more than a paid one would. If anything, the absence of a licence fee makes the discipline more important, because there is no vendor invoice forcing you to ask where the money goes. The GPUs already serving your vector store may well have the headroom for the load you are about to buy a second instance to handle. You will only know if you profile them. Our own GPU-focused engagements consistently find that the first question — “how much of the existing fleet does this workload actually use?” — is the one that was never asked. FAQ Is Milvus open-source? Yes. Milvus is released under the Apache 2.0 licence — you can self-host, modify, and ship it without a licence fee. The licence removes the software cost only; it does not remove the GPU infrastructure cost of running a self-hosted deployment. What licence does Milvus use, and what does ‘open-source’ actually cover versus the managed Zilliz Cloud offering? Milvus uses Apache 2.0, which covers the core database, query nodes, index engines, and SDKs. Zilliz Cloud is the separate commercial managed offering from the company behind Milvus — you pay a service fee, and they own the hardware and tuning. The open-source licence covers the software you self-host; it does not cover the operational or GPU cost of running it. Does Milvus use the GPU, and which operations can be GPU-accelerated? Yes. Milvus supports GPU-accelerated index build and vector search via NVIDIA’s RAFT/cuVS libraries, through GPU index types such as GPU_IVF_FLAT and GPU_CAGRA. Both constructing the ANN index and running query-time similarity search can be offloaded to the GPU, which is what turns the licensing question into a hardware-utilisation one. If the software is free, where does the real cost of a self-hosted Milvus deployment show up on the GPU bill? In idle and under-utilised GPU capacity. Index build is often I/O-bound, leaving cores idle during ingest; vector search at small batch sizes leaves HBM memory bandwidth unused. Both translate directly into cost per useful vector operation — the metric that matters — rather than cost per provisioned GPU. How do I profile GPU utilisation for a Milvus vector-search workload before sizing capacity? Profile index build and query serving separately, because they have opposite bottleneck signatures. Watch achieved memory bandwidth rather than the coarse utilisation percentage, measure at realistic batch sizes and concurrency, and compute cost per useful operation instead of cost per hour. Should I provision additional GPU capacity for Milvus or first measure how much of my existing fleet the index actually uses? Measure first. A free licence removes the vendor invoice that would normally force the question of where the money goes, so the discipline of profiling matters more, not less. Existing GPUs often have headroom for the load teams are about to buy a second instance to handle — profiling is the only way to know. What GPU utilisation gaps are common in vector-database workloads, and how do batch size and ingest patterns leave capacity on the table? Two gaps recur: I/O-bound ingest that leaves GPU cores idle while vectors are read from storage and moved across PCIe, and small-batch search that leaves HBM memory bandwidth unused because there isn’t enough work in flight to saturate it. Bursty query patterns amplify both, producing a GPU that reports “busy” while delivering a fraction of its throughput. A self-hosted Milvus GPU deployment is exactly the kind of workload a GPU performance audit is built to measure: the licence is free, but the audit quantifies whether the silicon behind the vector store is actually being used. The failure class here is not licensing — it is provisioning capacity for an index nobody profiled, then paying monthly for utilisation nobody verified. Free software is a fine starting point; it is not a reason to skip the measurement.
