Which Milvus deployment mode fits your team
Use Milvus Lite for prototypes, Standalone for single-machine production up to about 100 million vectors, and Distributed on Kubernetes for larger collections. Lite is a Python library you import into an application, and the installation overview recommends it for datasets up to a few million vectors. Standalone packs the whole service into one Docker image, so it suits production teams that do not run Kubernetes. Distributed separates ingestion from search and is aimed at collections from 100 million to tens of billions of vectors. The mode is not decided by feature needs alone, since all three expose the same core APIs. It is decided by dataset size, how much downtime your users will tolerate, and whether your team can operate etcd, object storage and a message queue.
Lite matters when the question is whether your retrieval approach works at all. It has the lowest setup effort and keeps the data in a local file, but it is not the place to find out how the service behaves under concurrent writes or failover. Standalone matters when you need a durable, self-hosted service on one host and your collection stays under the stated ceiling. Its operating burden is smaller, yet a single machine is still a single failure domain, so you should plan backups and a restore test before go-live. Distributed matters when collection size, ingestion rate or availability requirements outgrow one machine. Each component is a separate service you run, patch and back up, so ask whether your platform team can own that load before choosing it.
Before you commit, confirm three things with Milvus documentation and your own load tests: your expected vector count at 12 months, your write pattern, and your recovery time objective. If you expect to move from Standalone to Distributed later, check the migration path in the Milvus installation overview and budget for a data move rather than assuming an in-place upgrade. Ask your DeployOpen or internal team to document which mode was chosen, the dataset size assumption behind it and the trigger that would prompt a review.
How Milvus Lite, Standalone and Distributed compare
This table compares the three Milvus deployment modes on form, documented dataset range, the message queue, object storage and metadata store each one needs, Kubernetes requirements, license and what changes when you move between them. Treat the dataset ranges as documented guidance and confirm them against your own workload before you commit to a mode.
| Dimension | Milvus Lite | Milvus Standalone | Milvus Distributed |
|---|---|---|---|
| Deployment form | Python library imported into your application process | Single machine, packed into one Docker image | Kubernetes-native cluster with separate ingestion and search |
| Documented dataset range | Up to a few million vectors, per the installation overview | Up to 100 million vectors, per the installation overview | 100 million to tens of billions of vectors, per the installation overview |
| Message queue | Confirm the write-ahead log path for your Lite version | Embedded Woodpecker | Woodpecker deployed as a dedicated service |
| Object storage and metadata store | Confirm local storage behavior in the Lite documentation | Default MinIO and etcd, confirm whether bundled or external | etcd plus MinIO, S3 or Azure Blob as separate services |
| Kubernetes required | No | No | Yes |
| License | Apache-2.0, same project | Apache-2.0, same project | Apache-2.0, same project |
| Who typically runs it | Application developers prototyping in Python | Teams wanting production without Kubernetes | Teams already operating Kubernetes with larger collections |
| Moving to another mode | Plan a data export and reload before moving to a server mode | Move to Distributed as collections grow or Kubernetes becomes standard | Adds etcd, object storage, queue and Kubernetes operations to run |
What every Milvus instance depends on
Every Milvus instance, whatever its deployment mode, depends on three supporting services: a message queue (the write-ahead log), object storage for the data files, and a metadata store. By default those are Woodpecker, MinIO and etcd. The practical decision is not whether you run these services but where they run and who operates them. Before you pick a mode, confirm which of the three you are allowed to host, which you must source from an existing enterprise service, and who holds the backup and restore duties for each.
The deployment modes differ in how they place the write-ahead log. In Standalone, Woodpecker is embedded in the single Docker image, so the queue lives on the same machine as the database. In Distributed, Woodpecker runs as a dedicated service on Kubernetes, which adds another component to size, monitor, upgrade and restore. The Milvus architecture overview lists Kafka and Pulsar as alternative write-ahead logs, and S3 or Azure Blob as alternatives to MinIO for object storage. If your organization already runs Kafka, S3 or Azure Blob under established controls, those options may reduce new operational work, but you must confirm with Milvus documentation for your release line which combinations are supported and tested. Before committing, run a short checklist in your own environment: confirm the Milvus release line you will deploy (v3.0.3 or v2.6.25 at the time of the supplied facts), confirm the chosen write-ahead log and object store are supported for that line, identify who owns etcd backups and object storage retention, and test a restore of all three components together. Ask your vendor or the project for the supported dependency matrix in writing, since a queue or object store that works in a lab may not meet your durability, encryption or access requirements.
Components and topology in each mode
Each Milvus deployment mode trades operating simplicity for the number of moving parts you must run, back up and size. The cards below walk through the components each mode needs, from the embedded library to a Kubernetes cluster with separate metadata, object storage and write-ahead log services.
Milvus Lite as an imported library
Milvus Lite is a Python library that your application imports, so the vector store runs inside your process with no separate server to deploy. It suits prototypes and small datasets, which the installation overview places at up to a few million vectors. Check that your data stays on one host, that no other process needs concurrent access to the same files, and that you have a plan to move the collection before it outgrows the library.
Standalone as one Docker image
Standalone packs the Milvus services into a single Docker image on one machine, and it uses embedded Woodpecker as its message queue. You run it without Kubernetes, which keeps the footprint small for a single-team production service. The installation overview suits it to datasets up to 100 million vectors. Confirm CPU, memory and disk sizing against your own vector dimensions, index type and query load, because the documentation does not set those for your workload.
Distributed on Kubernetes
Distributed runs as a Kubernetes-native cluster that handles ingestion and search separately, and it deploys Woodpecker as a dedicated service. Choose it when collections grow past what one machine should hold or when ingestion must not slow search. You take on cluster operations, including node pools, upgrades and monitoring. Ask whether your platform team already runs Kubernetes with the controls your security policy requires.
etcd as the metadata store
Every Milvus instance depends on a metadata store, which is etcd by default, and the architecture documentation places it behind the coordinators. In Distributed mode, etcd becomes a cluster you must keep healthy, back up and restore. Confirm who owns etcd backups, how restores are tested, and whether the cluster sits on storage fast enough for your write load. Sizing for etcd is not set by the supplied facts, so ask Milvus maintainers or your Kubernetes team to validate it.
Object storage for segment data
Milvus stores bulk data in object storage, which the architecture documentation lists as MinIO, S3 or Azure Blob. MinIO is the default in the installation overview, so a Standalone install runs it alongside Milvus. Using S3 or Azure Blob moves that data to a service you may already operate, but it changes your backup, encryption and access-control boundary. Confirm where the bucket lives, who holds its keys and how region placement meets your data residency rules.
Write-ahead log choice
The write-ahead log records incoming writes before they are flushed, and Milvus supports Woodpecker, Kafka or Pulsar for this role. Woodpecker is the default and is embedded in Standalone, while Distributed deploys it as its own service. Choosing Kafka or Pulsar adds a broker tier your team must run, monitor and patch. Confirm the write-ahead log choice and its recovery behavior with your Milvus release before you size the cluster.
When each mode fits a team's situation
Milvus Lite is a Python library that you import into an application, and the Milvus installation overview recommends it for datasets up to a few million vectors. It suits a developer testing chunking, embedding models and query patterns on a laptop or in a notebook. There is no separate service to start, so the availability model is simply the availability of the process that imports it. If that process stops, the vector index is only as durable as the local file it writes.
- Operations required: a Python environment and nothing else, with no Docker, Kubernetes, etcd or object storage to run.
- Availability trade-off: no redundancy. A crash or lost laptop loses the working copy unless you export the data.
- Data scope: keep the collection small and disposable, and treat it as test data rather than a system of record.
- Leave this mode when: the dataset approaches the few-million-vector guidance, more than one service needs to query the same collection, or the prototype is about to receive real user data.
Before you promote an application built on Lite, confirm the exact client and server APIs you rely on still behave the same on Standalone, and plan a re-index rather than assuming an in-place upgrade.
Milvus Standalone packs the deployment into one Docker image on a single machine, with the embedded Woodpecker message queue, and the overview describes it as suited to production without Kubernetes for datasets up to 100 million vectors. It fits one team that owns an application, wants a conventional container host and has no cluster to borrow. Availability is that of one machine: the database has no built-in node failover, so you need your own backup, restore and host recovery plan.
- Operations required: Docker on a host you can patch, monitor and back up, plus a tested restore procedure.
- Availability trade-off: a single point of failure. Plan for a maintenance window and for rebuilding the host from backups.
- Storage planning: size disk and memory for the collection, and check how the image stores its data before you choose volumes.
- Security setup: configure the authentication, TLS and role-based access control described in the Milvus README before exposing the port to other services.
- Leave this mode when: the collection nears the 100 million vector guidance, uptime requirements exceed what one host can offer, or several teams need separate scaling.
Confirm with the vendor and your own tests how Standalone behaves under your query load and what your recovery time looks like on your hardware.
Milvus Distributed runs on Kubernetes, separates ingestion from search, and the installation overview places it between 100 million and tens of billions of vectors, with Woodpecker deployed as a dedicated service. A platform team runs it as a shared service for several applications, which means the availability target is set by cluster design rather than by a single host. The architecture also needs etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log, so the dependency count is much higher than Standalone.
- Operations required: a supported Kubernetes cluster, etcd backup and quorum management, object storage operations and log or queue monitoring.
- Availability trade-off: redundancy is possible across nodes, but only if etcd, storage and the queue are each highly available.
- Tenancy model: use database, collection, partition or partition key isolation to separate teams on one deployment.
- Upgrade discipline: follow Kubernetes version skew rules and Milvus release-line changes before rolling upgrades.
- Leave this mode when: the operating cost of the extra services exceeds the scale you actually need, in which case a managed or smaller option may fit better.
Before committing, ask the platform team to confirm who runs etcd backups, how object storage is replicated and which Milvus release line will receive patches.
Upgrades, backups, monitoring and skills for each mode
This table compares how each Milvus deployment mode handles upgrades, backup scope, monitoring and the skills your team needs to run it. Read it as an operating checklist: the further right you move, the more components you own, and the release line you pick (v3.0.3 or v2.6.25) should match your own upgrade policy, which you should confirm with the Milvus project before committing.
| Area | Milvus Lite | Milvus Standalone | Milvus Distributed |
|---|---|---|---|
| Upgrade path | Upgrade the Python package in the application environment and retest the application against the new version. | Move one Docker image between release lines, with a backup taken first. Confirm the upgrade path between v3.0.3 and v2.6.25 in the release notes. | Upgrade Kubernetes-hosted components in sequence, coordinating with the Kubernetes version skew rules and the chosen Milvus release line. |
| Backup scope | Back up the local data directory used by the embedded database, since no separate services hold state. | Back up object storage, the etcd metadata store and the Woodpecker message queue data as one consistent set. | Back up object storage, etcd (using etcdctl snapshot save and tested etcdutl restores) and each queue service, on a schedule that keeps them aligned. |
| Monitoring | Monitor the application process and its disk usage. No cluster health views are needed. | Monitor the single container's resource use, disk, memory and query latency, plus the health of its embedded dependencies. | Monitor each service separately (proxies, coordinators, worker nodes, etcd, object storage and the queue), with alerts on quorum and replication lag. |
| Skills required | Python development and basic database file handling. | Docker operations, Linux administration, and backup and restore practice for three stateful dependencies. | Kubernetes administration, etcd operations, object storage administration, message queue operations and a tested incident runbook. |
| Who carries the work | The application team, usually without a platform team. | A platform or operations owner, with the application team as a consumer. | A dedicated platform team, with a named owner for each dependency and an on-call rota. |
| Recurring effort | Low. Mostly application dependency updates. | Moderate. Regular image upgrades, backup verification and capacity checks. | High. Ongoing cluster upkeep, etcd maintenance, Kubernetes upgrades and dependency monitoring. Ask any implementation partner to quote this work from a written scope. |
What running Distributed on Kubernetes adds to the work
Choosing Distributed means taking on a Kubernetes cluster before you take on Milvus. The kubeadm high availability guide describes two control plane topologies: a stacked control plane, where etcd runs on the same nodes as the control plane, and an external etcd cluster, where etcd runs on separate hosts. Both require at least three control plane nodes and a TCP load balancer in front of kube-apiserver on port 6443. Your platform team needs to decide which topology fits its failure domains before the Milvus chart is installed, because changing it later means rebuilding control plane members.
Etcd carries two responsibilities in this stack. Kubernetes uses it for cluster state, and Milvus uses an etcd instance for its own metadata. The Kubernetes documentation says etcd should run with an odd number of members, recommends five members in production, and requires a backup plan, with etcdctl snapshot save for backups and etcdutl for restores. Confirm that your backup schedule covers both etcd clusters, that you have rehearsed a restore, and that you know who runs it.
Upgrades add a second layer of planning. The Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, before kube-controller-manager, kube-scheduler and kubelets, and allows kubelets to be up to three minor versions older than kube-apiserver. Releases arrive about three times a year on a cycle of roughly 14 weeks, and the project maintains the three most recent minor releases. Check the support window of your own distribution, since managed or vendor-packaged clusters may lag upstream, and confirm which Milvus release line your cluster version supports before scheduling each upgrade. Security defaults also belong in this scope. According to the Kubernetes secrets good practices page, Secrets are stored unencrypted in etcd by default. Ask your platform team to confirm that encryption at rest is enabled for the Secrets that hold Milvus and object storage credentials, that list and watch access is limited by least-privilege RBAC, and whether an external store through the Secrets Store CSI Driver is part of the design.
Questions buyers ask before choosing a Milvus mode
How much more effort is Milvus Distributed than Standalone?
Distributed takes substantially more effort because it runs on Kubernetes and splits ingestion and search into separate services, with Woodpecker deployed as a dedicated service. Standalone packs the deployment into one Docker image on a single machine and is suited to production without Kubernetes for datasets up to 100 million vectors. Distributed adds a Kubernetes cluster to operate, plus the dependencies every Milvus instance needs: a message queue, object storage and a metadata store, which default to Woodpecker, MinIO and etcd. Before committing, confirm with your platform team who will own cluster upgrades, etcd backups and node sizing, since the Kubernetes version skew policy requires control plane components to be upgraded in a fixed order.
Can Milvus Lite move to production?
Milvus Lite is a Python library imported into your application and is recommended for datasets up to a few million vectors, so it is best treated as a prototype or development mode. Moving to production means choosing Standalone or Distributed and loading the data into a server deployment. Plan the move as a data migration and application change: the application must connect to a running server, and you should validate index settings, access control and backup procedures on the target mode before cutover. Whether your prototype's code and schema carry over cleanly depends on how much the application relies on Lite-specific behavior, which you should test rather than assume.
What drives cost in each Milvus mode?
Costs fall into compute, storage, the message queue, the metadata store and the people who run them. In Lite, cost is mostly the application host. In Standalone, you pay for one machine sized for your vectors and indexes, plus backups of the object storage and metadata. In Distributed, cost grows with the number of nodes, the etcd cluster (Kubernetes documentation recommends an odd number of members and a five-member cluster in production), object storage capacity, and the Kubernetes control plane. Most of the recurring cost is staffing time for upgrades, monitoring and backups. Ask any vendor or partner for an itemized quote covering hardware or cloud instances, storage, licenses for any support contract, and who performs each operational task.
How long does a migration between Milvus modes take, and what does it depend on?
Duration depends on collection size, the index types you rebuild, the number of collections and tenants, how much application code changes, and how much testing your environment requires. No supplied source gives a migration duration, so treat any figure you hear as unverified until it is tied to your data volume and scope. Start by measuring your vector count and growth rate, then run a rehearsal on a copy of production-sized data. Confirm with the vendor or partner whether the scope includes re-indexing, cutover testing, rollback and post-migration backup verification, and whether it is a fixed-scope engagement with a written timeline.
Can our team run Distributed Milvus without outside help?
A team with Kubernetes, etcd and object storage experience can run Distributed Milvus in house, but the work is continuous rather than one-time. Your staff would need to handle cluster upgrades on Kubernetes releases that arrive about three times per year, etcd snapshot backups with etcdctl and restores with etcdutl, secrets encryption at rest because Kubernetes stores Secrets unencrypted in etcd by default, and Milvus access control, TLS and role configuration. If you lack that depth, consider Standalone for the workload it fits or a managed option. Check your team's on-call coverage and certification plans against this list before deciding.
When should we hire a partner for a Milvus deployment?
Hire a partner when the work exceeds what your team can staff and audit alone, such as designing a Distributed cluster in your own cloud or data center, hardening it against your security baseline, documenting controls for an assessment, or migrating from a prototype under a deadline. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside the client's own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so ask for a quote tied to a written scope. Note that DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications.
Which Milvus mode fits a regulated team that must keep data in its own infrastructure?
All three modes can run inside your own infrastructure, so data location is usually decided by where you host the chosen mode, not by the mode itself. Lite runs inside your application process, Standalone runs on one machine you control, and Distributed runs across a Kubernetes cluster in your environment. Milvus implements authentication, TLS and role-based access control, but you must configure and verify them in each mode. Ask your security team which controls each mode must satisfy and whether the object storage and etcd locations meet your residency rules.
How to move from Lite to Standalone or Distributed
This sequence takes a prototype that runs in Milvus Lite and turns it into a Standalone or Distributed deployment with its storage, metadata and recovery path proven before any application traffic moves over.
Validate dataset size and index choice
The data owner and the platform lead confirm how many vectors the collection will hold now and in the next planning cycle, and which index type the prototype actually uses. Milvus's installation overview recommends Lite for datasets up to a few million vectors and Standalone for datasets up to about 100 million vectors, so a collection near either boundary should be sized again before you pick a mode. Distributed on Kubernetes is the option for larger collections. Confirm the index choice (HNSW, IVF, FLAT, SCANN or DiskANN) against the vendor's index documentation, because the index settings carry over to the new deployment. Done when the team has a written sizing note naming the target mode, the vector count and the index, and the sign-off is recorded.
Provision the message queue, object storage and metadata store
The platform team builds the dependencies that every Milvus instance needs. The default set is Woodpecker as the message queue, MinIO as object storage and etcd as the metadata store. In Standalone, Woodpecker is embedded in the single image, so the work is mainly the MinIO bucket and etcd. In Distributed, Woodpecker runs as its own service, and the team must also plan etcd membership and backups, since Kubernetes guidance calls for an odd number of etcd members and a backup plan. Ask the vendor which object storage (MinIO, S3 or Azure Blob) your data residency rules allow. Done when each dependency answers a health check from the Milvus host and etcd snapshots can be written to a test location.
Reconfigure connections and access before loading data
This step changes the connection and access setup that the Lite prototype hid. Lite is a Python library that opens a local file, so the application passes a file path and no credentials. Standalone and Distributed expose a network endpoint, so the application must receive an address, a user and a password or token, and TLS settings. Milvus implements authentication, TLS and role-based access control, so the security team should create service accounts with the least privileges the application needs and confirm that TLS is enabled on every client path. Retire any hard-coded local file path in the application configuration. Done when a test client connects over TLS with a restricted account and the application configuration no longer references a local Lite file.
Move the collections and reload the indexes
The team exports the collection schema, vector data, scalar fields and partition or tenancy layout from the Lite database, then recreates the collection on the target deployment and loads the data in batches. Recreate the same index types and parameters that the sizing note recorded, and rebuild indexes on the target rather than copying files between engines. Check that row counts match the source for each collection and partition, and spot-check search results for a fixed set of test queries against the Lite baseline. Done when counts match, the test queries return the same top results within the tolerance the application expects, and the load job logs contain no unresolved errors.
Test backup and recovery on the new deployment
Before any traffic moves, the operations team proves it can restore. Back up the object storage data and the etcd metadata, then restore both into a separate environment and confirm the collections are queryable with the same counts. The etcd side follows the Kubernetes approach of taking a snapshot with etcdctl and restoring with etcdutl. Record who runs the restore, how long it took in your environment, and where the backup copies are kept, because the recovery path depends on the metadata and object storage being restored together. Done when a restore into the test environment passes the same count and query checks and the runbook records each command used.
Cut over the application and retire the prototype
The application team switches its configuration to the new endpoint, using the restricted service account and TLS settings from the access step. Run the old and new paths in parallel for a short observation window that the team sets in its own change plan, comparing query results and error rates. When the comparison is clean, point all writes to the new deployment and freeze the Lite file as a read-only archive. Done when the application runs on the new endpoint, the rollback steps are documented and tested, and the Lite file is archived with a recorded checksum.
How DeployOpen scopes and delivers Milvus deployments
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Milvus, that means matching the deployment mode to your data volume, access model and operating capacity before anything is installed.
How we scope
- Confirm expected vector count, growth rate and whether the collection will stay on one machine or need Kubernetes.
- Record which teams, tenants and data classes will share the database, since multi-tenancy choices affect the mode.
- Agree in writing which of Lite, Standalone or Distributed is in scope, and which upgrade path is excluded.
- Define whether etcd, object storage and the message queue are provisioned by your team or by the engagement.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Install the chosen mode, configuring authentication, TLS and role-based access control as the written scope requires.
- Set up the metadata store, object storage and Woodpecker or the configured write-ahead log for the target mode.
- Test ingestion and search against representative collection sizes, including backup and restore of the data path.
- Document network placement, persistent volume sizing and the dependency versions pinned for the deployment.
- Where Distributed is chosen, configure Kubernetes components, etcd backups and control plane topology per the scope.
How we hand over
- Deliver runbooks for startup, shutdown, scaling and upgrades that match the deployment you actually run.
- Provide backup and restore procedures for etcd and object storage, tested on your environment before handover.
- Hand over access control records, certificate ownership and the list of components your team must maintain.
- Document the evidence and configuration needed for your own compliance assessment, without issuing any attestation.
- Walk your operators through the architecture, including where the write-ahead log and metadata live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Plan Milvus version upgrades against the release lines your team chooses to follow, with testing before each change.
- Revisit the deployment mode when collection size or tenancy changes, and scope the migration as a new engagement.
- Ask in any quote for who patches the operating system, Kubernetes and dependencies after handover.
- Confirm support response expectations in the written agreement, since DeployOpen does not publish SLAs.
