What Bubble actually costs at 10k, 50k and 200k Workload Units a month
Bubble publishes plan prices. It does not publish what your app costs. Those are different questions, and the gap between them is where the surprises live.
Lucian Lutas
Bubble publishes three prices: $29, $119 and $349 a month. None of them is what your app costs. What your app costs is the plan price plus however many Workload Units it burns past the allowance, metered at $0.30 per thousand with no ceiling on the monthly total.
So the useful question is not "which plan should we be on" but "what does this app cost at the usage it actually has". Here is that arithmetic at three usage levels, with the numbers computed from the same pricing config the cost calculator uses.
The allowances first
Everything below follows from these, and they are the part people get wrong. Starter does not include a token amount of workload. It includes 175,000 units, which is a real app's worth.
- Starter
- $29
- Growth
- $119
- Team
- $349
| plan | included | overage | per month | per year |
|---|---|---|---|---|
| Starter | 175,000 | none | $29 | €301 |
| Growth | 250,000 | none | $119 | €1,236 |
| Team | 500,000 | none | $349 | €3,626 |
At 10,000 Workload Units a month you are nowhere near any allowance. This is a side project, an internal tool, an app with a few dozen users. The Free plan covers 50,000 units, but it cannot deploy a live version, so the moment you need a real domain you are on Starter, and Starter is the answer until something below changes.
50,000 units: still nothing interesting
- Starter
- $29
- Growth
- $119
- Team
- $349
| plan | included | overage | per month | per year |
|---|---|---|---|---|
| Starter | 175,000 | none | $29 | €301 |
| Growth | 250,000 | none | $119 | €1,236 |
| Team | 500,000 | none | $349 | €3,626 |
Still inside Starter's allowance, still €301 a year, and this is where a surprising number of live commercial apps sit. If this is you and somebody is trying to sell you a migration, the cost argument does not exist. Ask them what else they think is wrong.
200,000 units: the first surprise
- Starter
- $36.50
- Growth
- $119
- Team
- $349
| plan | included | overage | per month | per year |
|---|---|---|---|---|
| Starter | 175,000 | 25,000 | $36.50 | €379 |
| Growth | 250,000 | none | $119 | €1,236 |
| Team | 500,000 | none | $349 | €3,626 |
Here is where the instinct fails. You have passed Starter's 175,000 allowance, and the obvious move is to upgrade to Growth. Growth costs $119 a month. Staying on Starter and paying overage on the extra 25,000 units costs $36.50.
Upgrading would cost you about €857 a year to avoid €78 of overage.
This holds further than you would think
Run the comparison at any level and the same thing happens. Starter and Growth charge the identical $0.30 per thousand once you are over; the only difference is the base price and the allowance. Growth costs $90 more per month and includes 75,000 more units, which are worth $22.50.
So on Workload Units alone, Growth never catches up with Starter, and Team never catches up with Growth. At every usage level, the cheaper plan plus overage wins:
- starter + overage, at 500k WU
- $126.50 / mo
- growth + overage, at 500k WU
- $194.00 / mo
- team, at 500k WU
- $349.00 / mo
That is a genuinely strange pricing structure, and it is worth saying plainly: if Workload Units are your only reason to upgrade, do not upgrade.
Why you should upgrade anyway
The plans are not really priced on workload. They are priced on the things underneath it, and those are the reasons that actually justify the money:
- Editors. Starter allows one. The moment a second person needs to open the editor, you are on Growth, and the WU arithmetic stops mattering.
- File storage. 50 GB on Starter, 100 GB on Growth, 1 TB on Team. Above that it is $3 per 100 GB per month on any plan.
- Backup and version history. Two days on Starter, fourteen on Growth, twenty on Team. The first time you need to restore something from last week, this is the only line that matters.
- Server log retention. Same two, fourteen and twenty days. This is what you get to diagnose a Workload Unit spike with, which is a slightly cruel joke on Starter, the plan most likely to be surprised by one.
None of those is a workload argument. Buy the plan for the capability, then treat the overage as a separate, variable bill.
The caveat that could change all of this
Bubble sells workload tier subscriptions: buy units in advance for a volume discount. Bubble does not publish those rates anywhere we can find, and the FAQ tells you to check your own app's billing page.
That matters, because a tier subscription could plausibly beat every number on this page. If you are consistently paying overage, price a tier before you do anything else, and certainly before you talk to anyone about migrating. It is the cheapest lever available and it takes one page load to check.
When the number stops being fixable
All of the above is about paying the right amount for the workload you have. It says nothing about whether the workload itself is reasonable, and that is usually the real problem.
A Workload Unit bill that climbs month over month while your user count stays flat is not a pricing problem. It is an app that is doing work nobody asked for: scheduled workflows still running against a removed feature, searches with no constraint that get more expensive as your data grows, workflows that run on every page load because that was the quickest way to build them in 2023.
A workflow left running against a removed feature costs exactly as much as one doing useful work. A handful of those can account for a large share of a monthly bill, and switching them off is a change measured in minutes. It is worth checking before you conclude the platform is the problem.
That is the order to work in:
- Find out what is actually burning units. Bubble's Workload tab and your server logs, as far as your plan's retention allows.
- Fix the obvious waste.
- Price a workload tier against what is left.
- Only then ask whether the platform is the problem.
If you are still looking at a bill that grows with usage rather than with revenue after all four, that is when the migration arithmetic starts to make sense, and the calculator will tell you how long it would take to pay for itself, including when the answer is that it never would.