We’re experiencing a critical limitation with your Data API: the 100-record cap per call makes it practically impossible to work with datasets of any meaningful size.
The problem isn’t just the pagination itself — it’s that consecutive API calls from external clients get blocked or timeout after the first request, making it impossible to reliably fetch more than 100 records even with proper cursor-based pagination.
To make matters worse, backend workflows have the same limitation, so there’s no native way inside Bubble to perform aggregations (like distinct count) on datasets larger than 100 records.
This is a fundamental blocker for any serious data analytics use case. Competitors like Xano, Supabase, and Firebase handle this without any issues.
Requested improvements:
Increase the API limit to at least 1,000 records per call
Fix the consecutive call blocking behavior
Add native distinct count aggregation in backend workflows
This is not a feature request — it’s a bug that makes Bubble unsuitable for production apps with real data volumes.
It’s not a bug. It’s a safety feature to protect the shared shards that non enterprise plan apps live in.
If you are aggressively making requests to your Bubble database then you should switch to an enterprise plan. If that’s too expensive for you then you made fundamentally wrong decisions in your architecture.
Hey @gerard - Bubble has the flexibility to return this and much more using a custom API response. You can access all the data aggregation tools from the editor (count etc.) and with more customization.
Below, is a sample from a dataset with 10,001 records (but the scale can be much larger)
You can use the ‘return data from API’ action in a Backend Workflow>
Consecutive calls themselves are not the problem. If you are making consecutive calls too fast then you are hitting Bubble’s rate limits for shared servers. Which IMO is what you are doing.
Edit: Hence why the solution shared by @DjackLowCode works. Less calls larger payloads
