[New Thread] More context on our changes to pricing - FAQs answered

We have closed comments in this thread and have published a new update from @josh: An Update to Workload, Plus More Transparent Calculations

To our community -

For those of you I have not yet connected with, I am Tatiana Afanasyeva, Bubble’s VP of Marketing. Thank you for the discussion on the forum. We know we can always count on the community to provide feedback, and we’re very grateful to each of you for taking the time to provide it. While any pricing change is difficult, we know that many of you run your businesses entirely on Bubble, and that makes this an even more significant adjustment. We don’t take this lightly.

When we look at the specifics of this change, we see that if every paying app switched today without optimizing at all, 92% of apps would see less than a $250/month change, and 83% would see less than a $50/month change. For some apps, the change is much larger, and many of you are represented in this forum thread. We knew going into this that some apps would see very significant increases. In our analysis of our user base, our team was either able to find massive workload optimization opportunities (sometimes >95%), or we felt that the app represented a thriving business that could support the increased price. If your workload is greater than 40M WUs, please contact our sales team to discuss a custom plan: Contact sales | Bubble

We are committed to making this work for all of you, and over the last day we have continued reaching out 1:1 to our most impacted users to offer hands-on optimization support. We will continue to support you throughout the 18-month legacy period and beyond. Additionally, we invite you to attend our upcoming live webinar on April 20th, which will provide further guidance: https://bble.io/workloadwebinar

Please do not hesitate to reach out to our support team at support@bubble.io if you still have questions or concerns. We are always here to help.

Now, we want to take the opportunity to respond to some of the themes that came up yesterday:

Bulk data operations

One of the biggest concerns we’ve heard is that in Bubble today, bulk data manipulation is just intrinsically costly in terms of workload. When working in native code, you generally get economies of scale when you are importing, exporting, or modifying thousands or millions of records at a time. In Bubble today, that’s not the case.

Changing this is one of our biggest priorities this year. You should expect to see noticeable improvements in Q3, both in terms of workload consumed and speed of operations. This is an area we’ll continue to work on for the remainder of the year.

Same goes for recursive scheduled workflows. For many of the apps we investigated before announcing the new pricing, one or two recursive workflows accounted for almost all the workload consumed. These recursive workflows are often workarounds to deal with Bubble’s lack of strong native bulk data manipulation capabilities, and we anticipate massive workload savings to come from this.

File storage

Given Bubble’s scale, we’ve identified file storage as an area we can make significantly more affordable in the new pricing model. Each of the paid plans should see at least 4x the previous storage amount included relative to previous plans. The following storage will be included in each of the plans and you are able to purchase additional monthly file storage at $3 per 100 GB.

  • Free: 0.5 GB
  • Starter: 50 GB
  • Growth: 100 GB
  • Team: 1 TB
  • Agency: 2 GB

Free Plan changes

While we will continue to have a 200 limit on database things, apps on the Free plan will have new access to version backup and database backup, plus longer retention windows for server logs.

What contributes to workload

Workload is measured in units, and users should not think about workload units in terms of 1 workflow action = 1 unit. The exact calculation of workload is based on behind-the-scenes implementation details, but in general, the more data that gets processed by Bubble, both in terms of number of things and size of things, the more workload will be consumed.

Some examples:

  • Most workflow actions have a base cost ranging from roughly 0.1 to 3 WU, depending on things such as whether conditionals passed and whether the action requires doing things on the server. Processing more data requires more workload; a “Change List of Things” action that modifies 20 things will be roughly twice as expensive as one that modifies 10 things.
  • Fetching a single item from the database has a base cost around 0.2 WU; extremely large database items cost more
  • All else being equal, searching the Bubble database for 20 items will consume roughly 2x the workload as searching the database for 10 items. External API calls (via the API and plugins) are somewhat more expensive, but the same rough order of magnitude as database searches
  • Almost everything the server does incurs at least some workload, but in practice, typical apps generally have their workflow usage driven by:
    • The amount of workflow actions they run, and how much data those workflow actions read and write
    • The amount of queries (both database and API calls) they make to render pages
  • Recursive backend workflows in particular tend to consume a lot of workload. This is generally not due to them being more expensive than other workflows (there is a small workload cost to schedule them, but it is generally no more than the cost of any other workflow action), but rather because they run over and over again

In practice, our recommendation for optimizing your app is not to take a bottoms-up approach of adding up how much each thing in your app does. Rather, we think the easiest approach is to test the app and use our charts to drill into which workflows, searches, and API calls account for the most workload. Once you have identified them, the questions to ask are “How often does this run?” “How many items of data does this read or write?” “Are any of those items of data very large?”

We plan to invest heavily in our analytics capabilities over the next several months to make it very easy to see exactly where workload is coming from, including enabling drilling down into individual workflow actions, and seeing how much workload a specific workflow run consumed in practice to allow rapid iterating.

For more, see our manual here: What contributes to workload? - Bubble Docs

Accidental usage

Our goal is to win because you win, not because of accidents. We understand that in the process of exploring and developing on Bubble, accidents happen. If you make a mistake, please reach out to our team at support@bubble.io. We’ll deal with these instances on a case-by-case basis.


We know many of you are concerned about optimization - we hear the concern and we’re working hard on tools and resources not only to clarify workload and the related concepts but also to help you debug your own apps and investigate your workload usage so you can make more informed decisions. As mentioned at the beginning of the post, we highly encourage you to attend our upcoming session on April 20th where we’ll discuss strategies and best practices: https://bble.io/workloadwebinar. We’re also still scheduling 1:1 sessions with anyone interested in connecting with the team regarding app optimization.

We are committed to working hands-on with users over the next 18 months to help optimize apps, and we will continue to invest in resources and tooling to enable this process. In addition to better drill downs and analytics, we plan to fix any feature bottlenecks that would make it prohibitive to run certain use cases. As mentioned above, we plan to invest in improving bulk data operations, and as other issues come up as we work 1:1 with you to optimize your apps, we will prioritize them as well. Your success is our success, and we appreciate your patience as we continue to invest in improvements to our platform and infrastructure.


So, you will go on with this price policy. OMG!!


Thanks for the clarification. Your estimates of WU usage do not reflect what a lot of users are seeing. How can we bridge this gap?


Unbelievable. The cost of WU is calculated somehow, which doesn’t means one action = one WU. Yay.

I can’t believe this pricing is going forward, looking at the previous thread where 95% of the users are unhappy.


Frankly, it would be a nightmare to have to be constantly worrying about and monitoring WUs, especially when we all know how ridiculously cheap computing power is.

It’s like I’m buying water at the price of Dom Perignon and have to spend every second fretting over each drop because it’s so expensive. Too much brain damage…


Database operations are much heavier than this…

Have you seen the empty create a thing tweet? Cost 6 WU to create an empty thing

Need a bit more clarity on these please…



haha, if you create an infinite loop by accident, dont forget to email the support or the lightning will strike !


So Bubble will invest in the coming months in Analytics and then will also invest heavily to support bulk operations … so meanwhile we just keep on working on a TRUST basis.

I think around 90% of the community would stop developing and would look for alternatives. The Analysis where Bubble costs are compared to similar operations in other Nocode platforms is of much concern.


Yeah, that’s something that has been established from the beginning.

So there is a bit of a dilemma here, I think in terms of timing.

At the moment, we don’t have those savings for bulk data manipulation.

So May 1st onwards, new apps can’t be built/optimized until those savings are realized in Q3/Q4…

Any suggestions on how to handle this in the meantime?



Wow, the definition of a WU unit is even more complicated than I thought previously.

I know you all had to make changes to shift the pricing model from performance / feature based to capacity based, but your pricing for capacity / workload units is so far and above the traditional cost of capacity on regular computing.

0.2 WU to fetch a single database item? So if I fetch a repeating group with 100 items, it’s 20 WU which is effectively $0.003? That doesn’t even factor in any filtering or conditionals. I can’t imagine for enterprise scale apps this is even close to feasible. The profit on this metric must be wild.

I don’t see why you all wouldn’t just make a little bit of money on Workload Units (more in line with traditional capacity pricing at places like Cloudflare or Lambda), and really make your money with the platform subscription / cost. THAT’S where I see people ok with 4 to 7x their cost.

This move just seems to box out those who are looking to grow on the platform. It just economically doesn’t make sense for anyone to build a scaling business on Bubble.


What a Sh*t-Show. I couldn’t work the whole day yesterday and today and I know that anyone who has invested years in Bubble would gone through the same.


We want a cost for capacity usage not for WU


Hey, @tatiana.a! Welcome to the forum…yikes @emmanuel @josh are you guys too busy to chime in yourselves?


I’ve been here since 2015, back then bubble tried visitor-based pricing - it was horrible. Feels like we are going backwards. I’m looking at alternatives and of course building things outside bubble as quickly as possible. This is the result of them raising $450M and bringing in the money hungry VCs.


An important question - when doing your analysis are those percentages (ie 92% of apps seeing a $250/month change) taking into account EVERY app on the platform (many of which are dormant / very low usage)?

Or did it take into account only apps that actually have users?

This is an important distinction and if not taken into account would completely skew the analysis of how to price apps.


How does Bubble intend to deal with DDoS attacks or simple HTTP request bots?
How will it be possible to prove that an excess load (and consequently a high charge) is due to any of these factors?


My new app that I’ve been building for 15 days used 2M+ WUs, not even live yet. Totally unaffordable.


Has anyone else used Bubble to build a personal/portfolio website? It made the most sense to me a couple years ago because I use Bubble at work and it could very easily handle the different ways of organizing artwork and projects I wanted to showcase because of the database backend.

My portfolio site uses less than 10k of workflows per month, so I’m now looking at paying an extra $50 a year just to keep the custom domain. I know this is an unusual use case, so Bubble isn’t particularly incentivized to provide solutions for this, but IMO there should be a personal/hobby tier available at a price point that reflects how little of Bubble’s resources those sites use up.


I’d love to see the data that shows how they concluded that most apps will have enough WUs. Such a BS.