# Bubble scaling limits: which ones actually bite > Bubble publishes its hard limits. Most never touch you. See which ones decide whether an operation can keep growing on the platform, and which are just noise. - Author: Marlon Trettin - Published: 2026-08-21 · Updated: 2026-08-21 - Language: en - Canonical: https://yowpi.com/en/blog/bubble-scaling-limits-which-ones-bite --- Bubble publishes its hard limits, and most of them will never touch your app. The ones that decide whether an operation can keep growing are the sorted search capped at 50,000 things, the list field capped at 10,000 records, the five minute workflow timeout, and a bill that scales with how the app was built. The rest is noise. ## TL;DR - Bubble states plainly that it [does not rate limit](https://manual.bubble.io/help-guides/optimizing-an-application/hosting-and-scaling/scaling-with-bubble) your app. Speed does not degrade as consumption grows, which rules out the most common assumption about hitting a ceiling. - The [documented hard limits](https://manual.bubble.io/help-guides/maintaining-an-application/performance-and-scaling/hard-limits) that bite in practice are on sorted searches, list fields and workflow duration, not on database size. - The real ceiling is usually commercial rather than technical: workload cost tracks how the app was built, not what it earns. - Hitting a limit is a design signal first. Some of these are fixable inside Bubble, and finding out which is cheaper than migrating. ## Does Bubble slow down as your app grows? No, and this is worth stating clearly because it is the assumption most teams arrive with. Bubble's scaling documentation says it in one line: ["We don't rate limit: Your app will run at the same pace no matter how much workload it consumes"](https://manual.bubble.io/help-guides/optimizing-an-application/hosting-and-scaling/scaling-with-bubble). That matters for the decision. If performance degraded with volume, growth alone would force a migration on a schedule you could predict. It does not. What grows with volume is the bill, and a bill is a different kind of problem: negotiable, sometimes fixable, and easy to ignore for one quarter too many. So the honest question is not "will Bubble slow down?". It is "which specific limits sit between my operation and where it needs to be in a year?". ## Which hard limits actually get hit? Four, in our experience, and they cluster around lists and long-running work rather than around raw data volume. **Sorted searches cap at 50,000 things.** Bubble documents that [a search with sorting applied returns a maximum of 50,000 things](https://manual.bubble.io/help-guides/maintaining-an-application/performance-and-scaling/hard-limits). Most apps meet this first, because reporting and exports are exactly where you sort a large set. It usually appears as a report that quietly stops being complete rather than as an error somebody notices. **List fields cap at 10,000 records.** The same page puts a hard limit of 10,000 records on list storage. This one hurts because lists are the most natural way to model a relationship inside a visual editor, and the fix is a data model change rather than a setting. **Workflows time out at 300 seconds.** Anything running more than [five minutes will time out](https://manual.bubble.io/help-guides/maintaining-an-application/performance-and-scaling/hard-limits). Batch jobs, month-end processing and bulk imports live right on this edge, and they get closer to it every month the business grows. **Pages cap at 10,000 elements, events and actions combined.** This is generous, and an app that reaches it is usually telling you something about how the page was built rather than about the platform. The limits people worry about in advance are rarely the ones that arrive. A single text field holds 10 million characters, one record can hold 20 MB, uploads go to 5 GB, and an app can define up to 1,000 custom data types. Those are not the constraints of a growing operation. ## What about the limits that are not technical? They are the ones that decide most migrations. Bubble bills server-side work in workload units, and its [pricing FAQ](https://manual.bubble.io/account-and-marketplace/account-and-billing/pricing-plans/pricing-faq) sets the base overage at $0.30 per 1,000 units when you have no workload tier subscription. The number itself is not the problem. The problem is what the number is attached to: consumption follows how the app was built, so two apps serving identical traffic can bill very differently because someone chose a search over a lookup, or moved a calculation to the server that did not need to be there. There is a harder edge on the same page. With overages disabled, an app that reaches its limit is taken offline and comes back at the start of the next billing period. That converts availability into a billing setting, and it is the single documented behavior that most often ends the debate internally. ## Is hitting a limit a reason to leave? Usually not on its own. A limit reached is a design signal before it is a platform verdict, and the order of investigation saves real money. Ask first whether the limit is structural or accidental. A sorted search capping at 50,000 in a monthly report is often a query that should have been filtered before sorting. A list field at 10,000 records is often a relationship that was modeled as a list because lists were easier. Both are fixable inside Bubble, and fixing them buys time. Ask second what the fix costs against what staying costs. In the [Colo Saúde platform](/en/cases/colo-saude) the first move was deliberately to stay: the app was stabilized on Bubble and its consumption cut by 60 percent, and only then did the rebuild begin. That sequence exists because runway decides whether the migration is calm or rushed. Ask third whether the limits you are hitting are the ones that will still be there at three times the volume. Some ceilings recede when you fix the query. The five minute workflow timeout does not recede, it arrives faster. When the answers point the same way, the decision framework is in [migrating from Bubble to custom code](/en/blog/migrating-from-bubble-to-custom-code). ## Frequently asked questions **Will my Bubble app get slower as it grows?** Bubble states it does not rate limit apps and that your app runs at the same pace regardless of how much workload it consumes. What grows with usage is the workload bill, not the latency. Slowness in a growing Bubble app is usually a query or page design issue rather than a platform ceiling. **Which Bubble limit do apps hit first?** In practice, the 50,000 result cap on sorted searches, because reporting and exports are where large sorted sets appear. It rarely announces itself: the report simply stops being complete. **Can I raise these limits?** The hard limits are hard. What you can change is whether your app needs to cross them, which is usually a data model or query decision. Workload is different: you can buy more, and that is a cost decision rather than a technical one. ## Next step If your app is brushing against one of these limits and you cannot tell whether it is the design or the platform, an Operational Architecture Diagnostic is a 30 minute conversation to separate the two before you commit to a rebuild. [Book a conversation](/en/contact).