Limits
Service limits, query defaults, and rate-limit responses.
Limits
These limits describe service interfaces in RawTree Cloud and RawTree BYOC. RawTree database settings also control query execution and results.
Query and insert limits
| Request or setting | Default | Result when exceeded |
|---|---|---|
| Table insert body | 104,857,600 bytes (100 MiB) | HTTP 413, error payload_too_large. |
| Insert requests | 1,000 requests per second per table within a database | HTTP 429, error rate_limit_exceeded. |
| Query request body | 52,428,800 bytes (50 MiB) | HTTP 413, error payload_too_large. |
Query result (max_result_bytes) | 104,857,600 bytes (100 MiB) | HTTP 400, error rawtree_error, with the default overflow behavior. |
Query execution (max_execution_time) | 30 seconds | HTTP 408, error request_timeout, for execution timeouts mapped by the Query API. |
| Query requests | 10,000 requests per second per database | HTTP 429, error rate_limit_exceeded. |
Body limits apply after request decompression. Splitting an insert into smaller requests can avoid the body limit, but each request counts toward the rate limit. An insert error does not guarantee that no rows were written. See table inserts before retrying an upload.
The Query API supplies max_execution_time and max_result_bytes as database
settings. SQL SETTINGS can change these defaults where database permissions allow it.
Database constraints and service transport timeouts still apply.
The database checks result size while it processes blocks. This value does not
describe the final encoded HTTP response size.
See max_result_bytes
and max_execution_time for their database semantics.
For JSONEachRowWithProgress,
a failure after HTTP headers arrives in the response stream or closes the connection.
HTTP 200 alone does not confirm a successful query.
Rate-limit responses
The table and database limits are shared across callers that use the same resource within an organization and cluster. Changing credentials does not create a separate allowance. The limiter replenishes capacity at the listed rate and permits bursts up to that capacity.
Successful query and table-insert responses include rate-limit headers when rate limiting is enabled.
Rejected requests return HTTP 429 with rate_limit_exceeded and these headers.
Other errors can omit the rate-limit headers.
| Header | Meaning |
|---|---|
x-ratelimit-limit | Maximum request allowance for the resource. |
x-ratelimit-remaining | Remaining allowance after this request. |
x-ratelimit-reset | Seconds until the allowance fully recovers, not a Unix timestamp. |
retry-after | Seconds to wait before retrying a rate-limited request. |
Wait for retry-after before retrying, then reduce the request rate.
Some temporary insert failures also include retry-after. Inspect the status and error body.
SQL formatter limits
POST /v1/query-format parses SQL without executing it.
Its limits are separate from query execution and ingestion limits.
| Limit | Value | Result when exceeded |
|---|---|---|
| Request body | 50 MiB | HTTP 413, error payload_too_large. |
| Formatted output | 100 MiB | HTTP 413, error payload_too_large. |
| Formatting time | 30 seconds | HTTP 408, error request_timeout. |
| Concurrent formatting requests | 2 per backend process | HTTP 503, error service_unavailable. |
The concurrency allowance stays occupied until the response finishes or the client disconnects. The formatter returns an error instead of partial formatted SQL.
Related
- Optimize queries
- Errors
- Apps API reference for protocol-specific behavior.