Xata applies some limits based on the plan level and the API endpoint in order to ensure reliable operation and scalability.
- User limits
- Schema limits
- Column limits
- Record limits
- Request limits
- Response limits
- File attachments limits
- Rate limits
|API keys per user||40|
|Workspaces per user||40|
|Databases per workspace||40|
|Tables per branch||100|
|Tables per workspace||1000|
|Database name length||255 chars|
|Branch name length||255 chars|
|Number of columns per table||256|
|id column length||255 chars|
|String column length||2048 chars|
|Text column size||200 KB|
|Multiple type total size||65536 chars|
|Record size||600 KB|
|Request size||20 MB|
|Bulk insert||1000 records|
|Page size||200 records|
|Offset pagination size||800 records|
|Cursor pagination depth||Unrestricted|
|File size (when using file binary APIs)||1 GB|
|File size (when using Record APIs)||20 MB|
|Query response size (when it includes file content)||20 MB|
|Number of files in a file array||50|
|Max ttl for a signed URL||24h|
Xata assigns capacity for request rate and concurrent connections at the branch level, in the form of billing units.
The Free plan grants a baseline of 3 billing units in each branch while additional units can be purchased.
The REST API may return HTTP response code
429 as a throttling error when the rate limiting conditions are met:
- Request rate limit: Total number of atomic HTTP requests submitted per second to any API endpoint under a branch
- Concurrency limit: Number of requests executing in parallel at any given moment within a certain Store of a branch
Xata uses three Store types with individual concurrency limits:
- Consistent transactional store: 2 concurrent requests / unit.
- Read replicas store: 3 concurrent requests / unit
- Search & Analytics store: 5 concurrent requests / unit.
- File attachments store: 2 concurrent requests / unit.
In case the concurrency limit in a Store is exceeded, requests to it are throttled internally with a timeout of 50ms. After reaching the timeout, the API errors with HTTP response code
For File attachments, the concurrency limits apply to CRUD and query operations on
file endpoints. For content sharing and high throughput scenarios, the direct access URLs should be used, which are NOT subject to rate and concurrency limits.
Xata's SDK clients throttle and retry
429 requests until they can be processed with the units available. Instead of throwing an application error when you have a significant amount of traffic, it degrades the speed without failing. Whenever a request needs to be throttled by the SDK, it prints an application log with the amount of extra time it took to be processed. To avoid noticeable speed impact in your application, you can increase the assigned units to your branch.
Tips & best practices useful to optimize requests for the Xata API:
- In case the client receives a
429response code from Xata, it means the request was not processed so your application can safely retry it.
- Log and track errors in your application error channels or log streams in order to monitor for throttling errors, so you can make informed decisions for adjusting the units assigned to your branch.
- For writing records to Xata, use the bulk endpoint instead of the atomic (individual record insert) data endpoint. The bulk endpoint allows batching of multiple records in a single request, which favors the optimal use of both your branch's request rate limit and concurrency slots in the transactional store.
- For requests to the
summarizeendpoits, consider using the
consistency: eventualoption to use the Read Replicas Store. This makes it less likely to reach the concurrency limit of either Store type and gets the best possible performance from your Xata branch's assigned units.