Which rate limiting mechanisms apply to Deta Base under high concurrent request loads?

Rate limiting mechanisms for Deta Base under high concurrency

Deta Base’s public documentation does not specify numeric rate limit thresholds, bucket sizes, or the exact throttling algorithm used for its REST API. Under high concurrent request loads, users typically observe HTTP 429 responses, often accompanied by a Retry-After header. These responses appear to be enforced at the serverless gateway layer, which commonly employs token bucket or sliding window patterns — however, Deta Base’s specific mechanism remains unconfirmed.

• Likely explanation: Serverless gateway layers typically implement token bucket or sliding window throttling to protect downstream services. This can cause 429 errors with Retry-After headers when request bursts exceed the gateway’s capacity.
• Confirmed fact: Excessive concurrent writes to a Deta Base dataset trigger 429 errors in practice, but the exact limit values are undocumented and appear to depend on the associated Deta account tier (free vs paid).

To verify the behavior for your specific setup, send a burst of requests to a Deta Base endpoint and record the HTTP status codes and response headers, particularly any 429 status and Retry-After values.

curl -X GET https://base.deta.dev/your-base/your-document

Note: Replace the URL with your actual Deta Base endpoint. This command is scoped to a single endpoint and does not modify data.

To refine the recommendation, could you specify your Deta account tier (free or paid) and the specific API endpoint being targeted? This detail would help narrow whether tier‑dependent thresholds are in effect.