Zilliz Cloud Limits
This page provides information about limits on the Zilliz Cloud platform. Submit a request to us if you need to report issues related to these limits.
Organizations, Projects & Members
The following table lists the limits on the maximum number of organizations and projects allowed for a single user.
Item | Max Number | Remarks |
---|---|---|
Organization | 1 | Zilliz Cloud automatically creates 1 organization upon successful account registration. If you need more organizations, please create a support ticket. A user can join multiple organizations. |
Project | 100 | Each user can create up to 100 projects in 1 organization. |
Organization and Project Member | 100 | An organization can hold up to 100 organization and project members in total. |
API Keys
Item | Max Number | Remarks |
---|---|---|
API Key | 100 | Each organization can contain a maximum of 100 customized API keys for optimal resource utilization and security. |
Clusters, CUs & vCUs
Clusters
The maximum number of clusters varies with your payment method and subscription plan.
-
Without a valid payment method
Subscription Plan
Max number
Remarks
Free
1
Only 1 cluster is available for the Free cluster plan. You can drop an existing cluster and replace it with a new one if required.
Serverless/Dedicated (Standard)/Dedicated (Enterprise)
1
You can only created 1 paid cluster in the free trial. If you would like additional clusters, please add a payment method.
-
With a valid payment method
Subscription Plan
Max number
Remarks
Free
1
Only 1 cluster is available for the Free cluster plan. You can drop an existing cluster and replace it with a new one if required.
Serverless
N/A
N/A
Dedicated (Standard)/Dedicated (Enterprise)
Total CU size < 320
The maximum number of clusters in an organization depends on the total amount of cluster CUs. The accumulated number of CUs for all Dedicated clusters in an organization should not exceed 320.
CUs
A CU is the basic unit of compute resources used for parallel processing of data, and different CU types comprise varying combinations of CPU, memory, and storage. The concept of CU only applies to Dedicated clusters.
Subscription Plan | Limits | Remarks |
---|---|---|
Dedicated (Standard) | CU size * Replica Count <=32 | On the console, you can create up to 32 CUs for a single cluster. However, the limit is CU size * Replica Count <=32 if replicas are added. |
Dedicated (Enterprise) | CU size * Replica Count <=256 | On the console, you can create up to 256 CUs for a single cluster. However, the limit is CU size * Replica Count <=256 if replicas are added. |
You are welcome to contact us
-
If your Dedicated (Standard)clusters require more than 32 CUs
-
If your Dedicated (Enterprise) clusters require more than 256 CUs
vCUs
A virtual compute unit (vCU) is used to measure the resources consumed by read operations (such as search and query) and write operations (such as insert, upsert, and delete). The concept of vCU only applies to Free and Serverless clusters.
Subscription Plan | Limits |
---|---|
Free | 2.5 million vCU per month |
Serverless | N/A |
Replicas
To add replicas, the cluster needs to have 8 CUs or more. The following limit applies as well.
Item | Limits | Remarks |
---|---|---|
Replica | 10 | You can create a maximum of 10 replicas. |
Replica count * CU size | <= 256 | The cluster CU size * Replica count should not exceed 256. |
Databases
-
Databases can only be created in Dedicated clusters.
-
Each Dedicated cluster can have up to 1024 databases.
-
Default database cannot be dropped.
Pipelines
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 |
Collections
Cluster Plan | Max Number | Remarks |
---|---|---|
Free cluster | 5 | You can create up to 5 collections. |
Serverless cluster | 100 | You can create up to 100 collections. |
Dedicated cluster | 64 per CU, and <= 4096 | You can create up to 64 collections per CU used in a dedicated cluster and no more than 4,096 collections in the cluster. |
In addition to the limits on the number of collections per cluster, Zilliz Cloud also applies limits on consumed capacity. The following formula shows how Zilliz Cloud calculates the general capacity of a cluster. The consumed capacity should be less than the general capacity available.
General Capacity = 512 x Number of CUs
The general capacity of a cluster indicates the maximum physical resources allocated to the cluster, and it can be determined using the following formula:
<= 512 x Number of CUs
For instance,
In a cluster of 2 CUs, you can create a maximum of 128 collections with a general capacity of 1,024.
In a cluster of 12 CUs, you can create a maximum of 768 collections with a general capacity of 6,144.
In a cluster of 32 CUs or more, you can create a maximum of 4,096 collections with a general capacity of 16,384.
The consumed capacity of a cluster indicates the physical resources consumed by the cluster.
For instance, let's assume that you have created 50 collections in a cluster; each of the first 20 collections has 20 partitions, while each of the remaining 30 collections has 10 partition. The consumed capacity of the cluster can be calculated as follows:
20 (collections) x 20 (partitions) + 30 (collections) x 10 (partitions) = 400 + 300 = 700
Based on the above calculation, Zilliz Cloud regards the cluster has a consumed capacity of 700.
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 |
Partitions
Cluster Type | Max Number (Per Collection) | Remarks |
---|---|---|
Free cluster | 1,024 | You can create up to 1,024 partitions per collection in a free cluster. |
Serverless cluster | 1,024 | You can create up to 1,024 partitions per collection in a serverless cluster. |
Dedicated cluster | 1,024 | You can create up to 1,024 partitions per collection in a dedicated cluster. |
When calculating the consumed and general capacity, refer to the notes in Collections. Additionally, the rate limit for creating partitions is 1 partition/s per cluster.
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.
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 | |
---|---|
Free cluster | 2 MB/s |
Serverless cluster | 10 MB/s |
Dedicated cluster 1 - 2 CUs | 8 MB/s |
Dedicated cluster 4 - 8 CUs | 12 MB/s |
Dedicated cluster 12 - 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 | |
---|---|
Free cluster | 2 MB/s |
Serverless cluster | 10 MB/s |
Dedicated cluster 1 - 2 CUs | 8 MB/s |
Dedicated cluster 4 - 8 CUs | 12 MB/s |
Dedicated cluster 12 - 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.
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.
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 Prepare Source Data.
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. |