Skip to main content
Rate limits help protect your applications from misuse and maintain the health of our shared serverless infrastructure. They vary by pricing plan and apply to serverless indexes only. Request-per-second limits are enforced per namespace or per index, as noted in the Data operation throughput limits table, in addition to your read and write unit limits, so a request fails if it exceeds any applicable limit. When you exceed a limit, the request returns a 429 - TOO_MANY_REQUESTS and the error message names the limit, scope, and value. Most rate limits can be adjusted upon request. If you need higher limits, contact Support with details about your use case.
Indexes built on Dedicated Read Nodes are not subject to read unit limits for query, fetch, and list operations. For sizing and capacity planning guidance, see the Dedicated Read Nodes guide.

Monthly usage limits

Read units and write units measure resource consumption. To check your current usage, see Monitor usage and costs. Monthly rerank request limits vary by model: Reaching a monthly usage limit returns a 429 - TOO_MANY_REQUESTS. Upgrade your plan to continue.

Data operation throughput limits

Exceeding a per-second throughput limit returns a 429 - TOO_MANY_REQUESTS. Implement retry logic with exponential backoff, pace your requests, consider Dedicated Read Nodes (which aren’t subject to per-second read limits) for high-throughput reads, or contact Support to raise a limit.

Model throughput limits

Per-minute token limits for embedding models: Per-minute request limits for reranking models: Reaching a per-minute model limit returns a 429 - TOO_MANY_REQUESTS. Upgrade your plan to increase it, or implement retry logic with exponential backoff.

Inference request limits

Exceeding the per-second or per-minute limit returns a 429 - TOO_MANY_REQUESTS. Implement retry logic with exponential backoff to handle it.
The message names the per-second or per-minute limit, whichever you exceeded.