Zilliz Cloud Limits

Contact Sales to Enable BYOC

This page provides information about limits on the Zilliz Cloud platform. You can use the OPS system that Zilliz provides to tune most of the settings mentioned on this page. You can still contact us if you need further help.

Organizations & Projects

The following table lists the limits on the maximum number of orgsanizations and projects allowed for a single user.

Item	Max Number	Remarks
Project	100	Each user can create up to 100 projects in 1 organization.

Collections

The maximum number of collections and partitions in a Zilliz Cloud cluster varies with the number of CUs allocated to it and its compatible Milvus version. You can refer to the following descriptions and calculate the maximum number of collections and partitions in your cluster.

Clusters compatible with Milvus v2.4.x

You can create a maximum of 256 collections or 1,024 partitions per CU, with up to 1,024 partitions allowed per collection. You can use the following formulae to calculate the upper limits for the number of collections and partitions in a cluster:

• The total number of collections in a cluster should be less than 256 times the number of CUs in the cluster or 16,384, whichever is lower.

• The total number of partitions across all collections in a cluster should be less than 1,024 times the number of CUs allocated to the cluster or 65,536, whichever is lower.

• Both conditions must be met.

Cluster compatible with Milvus v2.5.x

You can create a maximum of 1,024 collections or 4,096 partitions per CU, with up to 1,024 partitions allowed per collection. You can use the following formulae to calculate the upper limits for the number of collections and partitions in a cluster:

• The total number of partitions across all collections in a cluster should be less than 4,096 times the number of CUs allocated to the cluster or 65,536, whichever is lower, as denoted in the following formula:

• The total number of collections in a cluster should be less than 1,024 times the number of CUs in the cluster or 16,384, whichever is lower.

• Both conditions must be met.

Fields

Item	Max Number
Fields per collection	64
Vector fields per collection	4

Other limits on fields:

• Null values are not supported by any field types.

• Some fields, such as VarChar or JSON, use more memory than expected and can cause the cluster to become full.

Dimensions

The maximum number of dimensions of a vector field is 32,768.

Shards

The maximum number of shards allowed depends on the cluster plan and cluster CU size.

Cluster Plan & CU Size		Max Number
Free		2
Serverless		2
Dedicated	1-2 CU	2
	4-8 CU	4
	12-64 CU	8
	64 CU	16

Rate limit

Zilliz Cloud also imposed rate limits on collection operations, including creating, loading, releasing, and dropping collections. The following rate limit applies to collections in both Serverless and Dedicated clusters.

	Rate Limit
Collection Operation (create, load, release, drop)	5 req/s per cluster

Operations

This section focuses on the rate limit for common data operations in Zilliz Cloud clusters.

Insert

Each insert request/response should be no greater than 64 MB.

The rate limit that applies varies with the cluster types and the number of CUs in use. The following table lists the rate limits for insert operations.

	Maximum Insert Rate Limits
Dedicated cluster [1 CU, 2 CUs]	8 MB/s
Dedicated cluster [4 CUs, 8 CUs]	12 MB/s
Dedicated cluster [12 CUs, 20 CUs]	16 MB/s
Dedicated cluster [24 CUs, 64 CUs)	24 MB/s
Dedicated cluster [64 CUs, 128CUs)	36 MB/s
Dedicated cluster [128 CUs, 256CUs)	48 MB/s
Dedicated cluster >= 256 CUs	64 MB/s

When inserting data, include all schema-defined fields. Exclude the primary key if the collection has AutoID enabled.

To make inserted entities immediately retrievable in searches and queries, consider changing the consistency level in the search or query requests to Strong. Read Consistency Level for more.

Upsert

Each upsert request/response should be no greater than 64 MB.

The rate limit that applies varies with the cluster types and the number of CUs in use. The following table lists the rate limits for upsert operations.

	Maximum Upsert Rate Limits
Dedicated cluster [1 CU, 2 CUs]	8 MB/s
Dedicated cluster [4 CUs, 8 CUs]	12 MB/s
Dedicated cluster [12 CUs, 20 CUs]	16 MB/s
Dedicated cluster [24 CUs, 64 CUs)	24 MB/s
Dedicated cluster [64 CUs, 128CUs)	36 MB/s
Dedicated cluster [128 CUs, 256CUs)	48 MB/s
Dedicated cluster >= 256 CUs	64 MB/s

When upserting data, include all schema-defined fields.

To make upserted entities immediately retrievable in searches and queries, consider changing the consistency level in the search or query requests to Strong. Read Consistency Level for more.

Index

Index types vary with field types. The following table lists the indexable field types and the corresponding index types.

Field Type	Index Type	Metric Type
Vector Field	AUTOINDEX	L2, IP, and COSINE
VarChar Field	TRIE	N/A
Int8/16/32/64	STL_SORT	N/A
Float32/64	STL_SORT	N/A

Flush

The rate limit for flush requests is 0.1 requests per second, imposed at the collection level for specific cluster types. This rate limit applies to:

• Serverless clusters compatible with Milvus 2.4.x or later.

• Dedicated clusters upgraded to the beta version, compatible with Milvus 2.4.x or later.

📘Notes

You are not advised to perform flush operations manually. Zilliz Cloud clusters handle it gracefully for you.

Load

The rate limit for load requests is 5 req/s per cluster.

📘Notes

You do not need to perform the load collection for collections that are already loaded, even if new data is coming into these collections.

Search

Each search request/response should be no greater than 64 MB.

The number of query vectors that each search request carries (usually known as nq) varies with your subscription plan:

• For Free and Serverless clusters, the nq is no greater than 10.

• For Dedicated clusters, the nq is no greater than 16,384.

The number that each search response carries (usually known as topK) varies with your subscription plan:

• For Free and Serverless clusters, the topK is no greater than 1,024 entities in return.

• For Dedicated clusters, the topK is no greater than 16,384 entities in return.

Query

Each query request/response should be no greater than 64 MB.

Each query response carries no more than 16,384 entities in return (usually known as topK).

Delete

Each delete request/response should be no greater than 64 MB.

The rate limit for delete requests is 0.5 MB/s per cluster.

Drop

The rate limit for drop requests is 5 req/s per cluster.

Data import

You can have up to 10 running or pending import jobs in a collection.

Zilliz Cloud also imposes limits on the files to import on the web console.

File Type	Local upload	Sync from S3/GCS/Other OSS
JSON	1 GB	1 GB
Numpy	Not support	The maximum size of the folder is 100 GB and the maximum size of each subdirectory is 15 GB
Parquet	Not support	10 GB

For details, refer to Storage Options and Format Options.

Backup on Console

Manually created backups are permanently retained.

The maximum retention period for automatically created backups is 30 days.

Restore on Console

You can restore a snapshot in the same region as the original cluster of the snapshot. The target cluster of the restoration should use the same CU type as the original one.

IP Access List

Item	Max Number	Remarks
IP Address (CIDR)	20	You can add up to 20 IP addresses to the allow list.

Migration

You can migrate data from other vendors to your Zilliz Cloud cluster, and the maximum number of collections per migration varies with the subscription plan for your Zilliz Cloud cluster.

Subscription Plan of the Target Cluster	Maximum Number of Collections Per Migration
Free	5
Serverless / Dedicated	10

Pipelines

About to Deprecate

Number of pipelines

The following table lists the limits on different types of pipelines you can create in a project.

Pipeline Type	Max. Number (Per Project)
Ingestion Pipeline	100
Deletion Pipeline	100
Search Pipeline	100

Ingestion

The following table lists the limits on customized chunk size supported in each embedding model.

Embedding Model	Chunk Size Range (Tokens）
zilliz/bge-base-en-v1.5	20-500
zilliz/bge-base-zh-v1.5	20-500
voyageai/voyage-2	20-3,000
voyageai/voyage-code-2	20-12,000
voyageai/voyage-large-2	20-12,000
openai/text-embedding-3-small	250-8,191
openai/text-embedding-3-large	250-8,191

The following table lists the limits on metadata fields generated by a PRESERVE function in an Ingestion Pipeline.

	Max. Number
Number of metadata fields	50
The max_length of a VARCHAR field	4,000

The following table lists the limits on the number of chunks that are allowed to be ingested each time.

Embedding Model	Max. Chunks/Ingestion
zilliz/bge-base-en-v1.5	3,500
voyageai/voyage-2	6,000
voyageai/voyage-code-2	6,000
openai/text-embedding-3-small	6,000
openai/text-embedding-large	6,000
zilliz/bge-base-zh-v1.5	3,500

Pipeline usage

	Max. Usage
Each organization	$20/month

Token usage

The following table lists the limits on token usage.

Pipeline Type	Embedding Model	Max. Token Usage
Ingestion Pipeline	openai/text-embedding-3-small & openai/text-embedding-3-large	80,000,000
	Others	100,000,000
Search Pipeline	openai/text-embedding-3-small & openai/text-embedding-3-large	30,000,000
	Others	20,000,000
All Pipelines in an Organization	openai/text-embedding-3-small & openai/text-embedding-3-large	150,000,000
	Others	200,000,000

📘Notes

For the maximum token usage of all pipelines in an organization, the token usage of a dropped pipeline is still included in the overall count.