Skip to main content
Applies to:
  • Plan -
  • Deployment -

Summary

BTQL queries through the MCP server or API hit rate limits of approximately 20 requests per minute on Free and Pro plans, causing HTTP 429 errors that block productivity. Rate limits are enforced because BTQL queries consume significant backend resources and costs that aren’t accounted for in lower-tier plans. Contact sales to discuss increased rate limits for your organization’s usage requirements.

Resolution Steps

If you’re on a Free or Pro plan

Step 1: Contact sales

Reach out to discuss higher rate limits based on your usage patterns and requirements.

Step 2: Optimize queries while waiting

Reduce query frequency by caching results, batching requests, or adding time delays between queries.

If you’re self-hosting (Hybrid deployment)

Step 1: Configure rate limit environment variable

Set RATELIMIT_BTQL_DEFAULT to control queries allowed per object per minute.

Step 2: Update deployment configuration

For AWS deployments, add the variable to variables.tf. For GCP/Azure, update values.yaml in your Helm configuration.

Additional Information

Rate limit behavior

Rate limits apply per object (organization or project) and track queries over a rolling time window. All BTQL/SQL queries count including MCP server queries, API calls, UI filtering, SQL sandbox queries, and SDK queries.

Query timeout limits

Queries also have a 30-second timeout limit. Self-hosted customers can adjust this using BRAINSTORE_QUERY_TIMEOUT_SECONDS.

Retention window enforcement

Separate from rate limits, Starter and Pro plans enforce your plan’s data retention window (14-day retention on Starter, 30-day retention on Pro by default) on all SQL queries against logs and playground data. Experiments have up to 365-day retention on all plans. Data older than the window is silently filtered out rather than returned, so a query over older data returns empty results instead of an HTTP 429 error. Use a relative time interval to stay within the window.