Zilliz Cloud vs self-hosted Milvus

The Free tier in Zilliz Cloud suits early evaluation: a team testing index choices, embedding models or a retrieval prototype before committing budget. Zilliz's documentation lists it with no credit card required, which lowers the barrier to a first test. It is a managed service, so the vector data is held in Zilliz's infrastructure rather than yours, and it is not the place to put regulated data that must stay in your own environment.

• Who runs it: Zilliz operates the cluster, so you do not manage etcd, object storage or Kubernetes.
• Where data sits: Vectors and metadata are stored in Zilliz-hosted infrastructure, so confirm the region and provider before loading any real records.
• What to test: Index types, filtering and hybrid search against a representative sample, not production volume.
• What changes later: Moving from a free cluster to a paid tier or to self-hosted Milvus means reloading data, so keep your embedding pipeline and schema in code.

Before you rely on this tier, confirm the current collection, storage and throughput limits in the Zilliz Cloud documentation, and check whether the features you need are included at this level.

Serverless clusters suit variable traffic, such as a retrieval service with bursts of queries, a seasonal workload or a team that wants usage-based billing and no capacity planning. Zilliz documents them as billed by usage and able to scale to zero, so idle periods carry little or no compute charge. The trade-off is that you accept Zilliz's scaling behavior and service boundaries rather than tuning node sizes yourself.

• Who runs it: Zilliz manages scaling, upgrades and the underlying services.
• Cost pattern: Charges follow usage, so the bill rises with query and storage volume. Ask how usage is metered and what drives it.
• Data location: Data is held in Zilliz-managed storage, so confirm the regions offered and whether they match your residency requirements.
• Feature parity: Confirm which Milvus features, index types and access controls are available on Serverless before you design around them.

Before committing, ask Zilliz for written details on regions, latency expectations, scaling limits and the support terms that apply to this tier.

Dedicated clusters suit steady production load, where you want reserved resources and predictable performance for a known collection size and query pattern. The compute is allocated to your cluster rather than shared on demand, which helps when latency targets are tight. Data still lives in Zilliz's managed environment, so this tier answers capacity and operations questions, not placement questions.

• Who runs it: Zilliz operates the cluster, including the Milvus components beneath it.
• Capacity model: You choose resources to match the workload, so review sizing with Zilliz against your vector count, dimensions and query rate.
• Operational gain: You avoid running etcd, the write-ahead log and object storage yourself.
• Data location: Confirm the cloud provider, region and backup location in writing, since they determine where regulated data sits.
• Exit path: Ask how data can be exported and what migration support exists if you later move to self-hosted Milvus.

Before signing, request the sizing assumptions, maintenance windows and recovery objectives Zilliz commits to for this cluster type.

Bring Your Own Cloud runs the managed Milvus service inside a cloud account you own, which is the option most often considered when data-location rules are the main constraint but the team does not want to operate Milvus itself. Your vector data and object storage stay in your account, while Zilliz handles the service layer. Whether that split satisfies a specific regulator or internal policy depends on the access Zilliz needs and how the account is controlled, so this needs a formal review.

• Account boundary: Your cloud account holds the data and storage, which helps with residency and key management decisions.
• Operator access: Confirm what support access Zilliz has into your account, how it is granted and how it is logged.
• Network design: Ask whether private connectivity, IP allowlisting and encryption keys are under your control.
• Supported clouds and regions: Confirm the providers and regions available, since they limit where the deployment can go.
• Shared responsibility: Get the division of patching, backup and incident response in writing.

Before choosing this option, have your security and compliance teams review the access model with Zilliz, because the answer decides whether it meets your data-location requirement.

Self-hosted Milvus Distributed is the baseline for teams that must keep every component, key and log inside their own infrastructure. Milvus is Apache-2.0 licensed and runs as a Kubernetes-native cluster. Its architecture separates stateless proxies, coordinators and worker nodes, with etcd for metadata, object storage such as MinIO, S3 or Azure Blob, and a write-ahead log such as Woodpecker, Kafka or Pulsar. You gain full control of placement and access, and you take on the work of operating every dependency.

• Who runs it: Your platform team operates Kubernetes, etcd, object storage and the message queue.
• Data location: All vectors, metadata and logs remain in your data centers or cloud accounts.
• Security controls: Milvus implements authentication, TLS encryption and role-based access control, which you configure and test.
• Release lines: Milvus maintains v3.0.3 and v2.6.25 as separate release lines, so choose one and plan upgrades against it.
• Ongoing effort: Budget for backups, upgrades, capacity planning and incident response across each dependency.

Before you commit, confirm the expected cluster size, the storage and queue services your team can run, and who holds on-call responsibility for them.