Maximum limits on storage, workloads, and quantities of indexes, documents, and other objects depend on whether you provision Azure Search at a Free, Basic, or Standard pricing tier.
- Free is a multi-tenant shared service that comes with your Azure subscription. It's a no-additional-cost option for existing subscribers that allows you to experiment with the service before signing up for dedicated resources.
- Basic provides dedicated computing resources for production workloads at a smaller scale.
- Standard runs on dedicated machines, with more storage and processing capacity at every level. Standard comes in four levels: S1, S2, S3, and S3 High Density (S3 HD).
A service is provisioned at a specific tier. If you need to jump tiers to get more capacity, you must provision a new service (there is no in-place upgrade). For more information, see Choose a SKU or tier. To learn more about adjusting capacity within a service you've already provisioned, see Scale resource levels for query and indexing workloads.
Per subscription limits
You can create multiple services within a subscription, each one provisioned at a specific tier, limited only by the number of services allowed at each tier. For example, you could create up to 12 services at the Basic tier and another 12 services at the S1 tier within the same subscription. For more information about tiers, see Choose a SKU or tier for Azure Search.
Maximum service limits can be raised upon request. Contact Azure Support if you need more services within the same subscription.
|Resource||Free||Basic||S1||S2||S3||S3 HD 1|
|Maximum scale in SU 2||N/A 3||3 SU 4||36 SU||36 SU||36 SU||36 SU|
1 S3 HD does not support indexers at this time.
2 Search units (SU) are billing units, allocated as either a replica or a partition. You need both resources for storage, indexing, and query operations. To learn more about how search units are computed, plus a chart of valid combinations that stay under the maximum limits, see Scale resource levels for query and index workloads.
3 Free is based on shared resources used by multiple subscribers. At this tier, there are no dedicated resources for an individual subscriber. For this reason, maximum scale is marked as not applicable.
4 Basic has one fixed partition. At this tier, additional SUs are used for allocating more replicas for increased query workloads.
Per service limits
Storage is constrained by disk space or by a hard limit on the maximum number of indexes or documents, whichever comes first.
|Service Level Agreement (SLA)||No 1||Yes||Yes||Yes||Yes||Yes|
|Storage per partition||50 MB||2 GB||25 GB||100 GB||200 GB||200 GB|
|Partitions per service||N/A||1||12||12||12||3 2|
|Partition size||N/A||2 GB||25 GB||100 GB||200 GB||200 GB|
|Maximum indexes||3||5||50||200||200||1000 per partition or 3000 per service|
|Maximum indexers||3||5||50||200||200||No indexer support|
|Maximum datasources||3||5||50||200||200||No indexer support|
|Maximum documents||10,000||1 million||15 million per partition or 180 million per service||60 million per partition or 720 million per service||120 million per partition or 1.4 billion per service||1 million per index or 200 million per partition|
|Estimated queries per second (QPS)||N/A||~3 per replica||~15 per replica||~60 per replica||~60 per replica||>60 per replica|
1 Free tier and preview features do not come with service level agreements (SLAs). For all billable tiers, SLAs take effect when you provision sufficient redundancy for your service. Two or more replicas are required for query (read) SLA. Three or more replicas are required for query and indexing (read-write) SLA. The number of partitions is not an SLA consideration.
2 S3 HD has a hard limit of 3 partitions, which is lower than the partition limit for S3. The lower partition limit is imposed because the index count for S3 HD is substantially higher. Given that service limits exist for both computing resources (storage and processing) and content (indexes and documents), the content limit is reached first.
Per index limits
There is a one-to-one correspondence between limits on indexes and limits on indexers. Given a limit of 200 indexes, the maximum limit for indexers is also 200 for the same service.
|Index: maximum fields per index||1000||100 1||1000||1000||1000||1000|
|Index: maximum scoring profiles per index||100||100||100||100||100||100|
|Index: maximum functions per profile||8||8||8||8||8||8|
|Indexers: maximum indexing load per invocation||10,000 documents||Limited only by maximum documents||Limited only by maximum documents||Limited only by maximum documents||Limited only by maximum documents||N/A 2|
|Indexers: maximum running time||1-3 minutes 3||24 hours||24 hours||24 hours||24 hours||N/A 2|
|Blob indexer: maximum blob size, MB||16||16||128||256||256||N/A 2|
|Blob indexer: maximum characters of content extracted from a blob||32,000||64,000||4 million||4 million||4 million||N/A 2|
1 Basic tier is the only SKU with a lower limit of 100 fields per index.
2 S3 HD doesn't currently support indexers. Contact Azure Support if you have an urgent need for this capability.
3 Indexer maximum execution time for the Free tier is 3 minutes for blob sources and 1 minute for all other data sources.
Document size limits
|Individual document size per Index API||<16 MB||<16 MB||<16 MB||<16 MB||<16 MB||<16 MB|
Refers to the maximum document size when calling an Index API. Document size is actually a limit on the size of the Index API request body. Since you can pass a batch of multiple documents to the Index API at once, the size limit actually depends on how many documents are in the batch. For a batch with a single document, the maximum document size is 16 MB of JSON.
To keep document size down, remember to exclude non-queryable data from the request. Images and other binary data are not directly queryable and shouldn't be stored in the index. To integrate non-queryable data into search results, define a non-searchable field that stores a URL reference to the resource.
Workload limits (Queries per second)
|QPS||N/A||~3 per replica||~15 per replica||~60 per replica||>60 per replica||>60 per replica|
Queries per second (QPS) is an approximation based on heuristics, using simulated and actual customer workloads to derive estimated values. Exact QPS throughput varies depending on your data and the nature of the query.
Although rough estimates are provided above, an actual rate is difficult to determine, especially in the Free shared service where throughput is based on available bandwidth and competition for system resources. In the Free tier, compute and storage resources are shared by multiple subscribers, so QPS for your solution will always vary depending on how many other workloads are running at the same time.
At the standard level, you can estimate QPS more closely because you have control over more of the parameters. See the best practices section in Manage your search solution for guidance on how to calculate QPS for your workloads.
API Request limits
- Maximum of 16 MB per request 1
- Maximum 8 KB URL length
- Maximum 1000 documents per batch of index uploads, merges, or deletes
- Maximum 32 fields in $orderby clause
- Maximum search term size is 32,766 bytes (32 KB minus 2 bytes) of UTF-8 encoded text
1 In Azure Search, the body of a request is subject to an upper limit of 16 MB, imposing a practical limit on the contents of individual fields or collections that are not otherwise constrained by theoretical limits (see Supported data types for more information about field composition and restrictions).
API Response limits
- Maximum 1000 documents returned per page of search results
- Maximum 100 suggestions returned per Suggest API request
API Key limits
Api-keys are used for service authentication. There are two types. Admin keys are specified in the request header and grant full read-write access to the service. Query keys are read-only, specified on the URL, and typically distributed to client applications.
- Maximum of 2 admin keys per service
- Maximum of 50 query keys per service