More context on our changes to pricing

April 7, 2023 update: We’re closing comments on this thread and answering all of the most asked questions in a new thread for better visibility.

Hello everyone,

Today we announced changes to our pricing, and in particular, the introduction of a new metric to quantify an app’s usage on the Bubble platform. You can read a detailed description of what’s changing on our blog, but Josh and I wanted to say a few words here to the community as pricing has been an important topic on the forum.

First of all, we want to thank everyone for their patience and support in this process. We started with an announcement in March 2022, but we ended up pulling it back — we hadn’t gotten enough user feedback on the proposed changes and missed some important factors. Since then, we’ve spoken to hundreds of customers. I’ve personally connected with many of you in the past few weeks. We would not be where we are today without your feedback. We know many members of the community have been waiting for this update, so we’d like to take the opportunity to share some context.

Why are we changing the metric we’re using to quantify usage?

Our goal in approaching this pricing update is twofold:

  • Introduce a pricing model that allows apps to scale on the platform without the risk of being throttled
  • Ensure Bubble’s long-term success as a platform so that we can continue to support our customers’ businesses for years to come

In short, we are replacing our current usage-based metric, capacity, with a new metric called workload usage. We introduced the concept of capacity in 2017, at a time when Bubble was considerably smaller and less performant. This was a way to protect our infrastructure and ensure that no app could put too much stress on our systems. Back then, apps were being throttled very frequently, so we enabled users to purchase additional capacity credits to avoid getting rate-limited. However, this approach hasn’t been working well for users: often, peak usage on an application is precisely when you want it to run smoothly and efficiently.

Since then, we have significantly improved the scalability of our systems. While we still have limits to protect our infrastructure, we can afford to make those limits much higher, and we no longer need to worry as much about peak usage. Instead, we are enabling applications on paid plans to subscribe to a certain amount of workload usage over the course of a month, with the flexibility to pay-as-you-go on overages if and when they need to. These improvements mean that apps are less likely to hit issues when they have the most usage, and end-users will get more consistent performance. This is also better for Bubble as a business: it ensures that our pricing scales with how much usage an app has, which allows us to keep Bubble affordable for our earliest-stage builders.

This change also solves a fundamental factor to Bubble’s long-term success. What we didn’t realize in 2017, when we introduced capacity, is that as we improve the performance of our systems, applications are less likely to hit peak capacity. This creates a perverse incentive for us: as our team improves Bubble and makes it faster and better, Bubble’s revenue from capacity goes down. As we have sped things up over the last several years, we have seen more of our revenue come from feature plans than from capacity. This would put pressure on us to make features much more expensive, which is at odds with our fundamental philosophy: We do think we should charge for certain features, but we want Bubble’s growth to be driven primarily by users scaling up on our platform. (In other words, we want to succeed because you succeed.)

Workload solves this problem because it measures the amount of work an application needs to do, like the underlying data retrieval and manipulation, API connections, and web interactions. How fast Bubble performs this work does not change the way workload is computed, so as we continue to invest in Bubble’s performance, incentives remain aligned.

What’s the impact on existing users?
Today, new charts showing your app’s workload consumption are available in the editor, but nothing changes yet on the pricing side — as mentioned in our blog post, all existing applications will have the option to maintain their current plan’s structure, with a 10% price increase, for 18 months (until October 1st, 2024). On May 1, the new plans will be available for both new and existing applications.

Because we are changing the way we price Bubble, this shift will affect some apps more than others. If the new pricing structure increases the cost of your app, here are some things to keep in mind:

  • You can remain on your old plan for 18 months to give yourself plenty of time to optimize your application. To that end…
  • Your app hasn’t been optimized yet. Since workload is a new concept, most of our customers’ apps are not designed to minimize workload consumption. Our team has analyzed many apps, and on average, we were able to reduce consumption by 30-40% pretty quickly, without degrading the user experience. Some apps can be optimized even more dramatically: we found apps where 95% of workload was consumed by a single recurring workflow.
  • We’re here to help with optimization. We’re going to publish content and organize webinars to help people understand how to optimize their apps - our first session is coming up in two weeks (link here!) and more will be scheduled in the coming days. We’re already working with some community leaders to produce content in other languages to help train the community faster.
  • If you are noticing high usage patterns in your app, our team is available at for help. We want to make sure Bubble remains the solution of choice for your business.

We want this transition to be as smooth as possible for everyone, and our team will be available over the next 18 months to make sure of it. If you’re unsure whether your app can scale with Bubble, reach out to our team and we’ll figure out how to help you succeed on the platform.

Price changes to legacy plans

As mentioned above, you can choose to keep your app on its existing plan, using capacity, for 18 months (October 2024). Starting May 1, the price of these plans will increase by 10%, and you’ll see that reflected on your following invoice.

This increase will make a significant difference for Bubble, as we haven’t changed our prices since 2019. It will allow us to invest in areas of the product that we have not yet been able to prioritize — particularly the mobile experience.

You have the option to switch your app to a discounted yearly plan before May 1 and lock in this legacy rate for a year. This can be done easily in the App Plan tab in the editor.

Thank you for being a part of our journey

Thank you, everyone, for your patience and understanding during this process. We started talking about a new metric in March 2022. We’re happy we’ve finally released plans and pricing that will enable our users to scale better on the platform and ensure Bubble’s long-term success while remaining accessible for people to launch businesses. I’m excited we can roll this out today and move forward — we have a lot of exciting things we want to build to improve the platform.

Emmanuel & Josh


I made a quick explainer video here!

tl;dr I like using a water analogy to explain to my clients.

We used to have unlimited water but a thin pipe connected to our app throttled performance calling bubble ‘slow’.

In the new model, we will have a limited bucket of water and unthrottled access to it.

Some of our client projects are 10million workload unit+. Time to dig into some optimization techniques.

Need to optimize the app to make sure the bucket lasts much longer.



Finally, API connector in a free plan :tada:


Together with different Bubble experts (JJ Englert and @gregjohnkeegan) as well as Bubble itself, we wrote this article to understand the origins of this new pricing model, its details, and what it means for users.


  • Origins of this new pricing model
  • Detail of the new pricing model (metric, features, add-ons, etc…)
  • Roll-out for existing users
  • Our analysis

Read the article

Bubble Update

:link: Analysis of New Pricing Model | Flusk Blog


You had me at 10 branches.


They had me at the generous 18-month grace period to figure all of this out and optimize our apps… and they are gladly going to help us do the latter, too.


And well documented this time :+1::


I like the interactive drill down here


Guess I’ve got a lot of optimizing to do :sweat_smile:


hi, however helpful the analogies presented above, i think racing to get the first reply to this thread with a pre-prepared video or blog, as some people have done above, is inappropriate.
You have used the trust and information given to you, 80% for selfish promotional purposes.
You can do better than that!

My thoughts.
Charging for capacity makes most sense for bubble as bubble is basically reselling AWS servers with an easy to use interface on top that manages backend and frontend.

My hopes.
I would really like to see bubble improve recursive workflows and list operations, as they consume a ton of capacity but are so necessary to manage databases of 1M records plus.
Backend workflows are a core USP of bubble compared to simpler nocode builders. Many businesses investing in bubble do so pre-revenue or with just 1000 users but 1M rows of data. Using other backends would require much less capacity for the same operations.

So often I create things in the database just as I need them for another step or have to use advanced filters or daisy chained api workflows just for pretty easy list intersects that just work with SQL

Charging by capacity is the right thing to do but in 18 months will penalize me for Bubble’s inefficient ways to handle certain things in the backend so I hope for progress in that aspect. A smart thing to do would be to benchmark bubbles performance with that of other backends. I understand you guys want to make a profit and want you to make one, and if you improve backend workflows to make them faster, this leads to less revenue when charging by capacity, but at some price point I also have to leave the bubble backend to save $$ and that’s worse for bubble.


In the world of no code, I appreciate always your transparency and commitment to supporting the community.
I’m excited to see how these changes will help me and other no coders build even more powerful applications with Bubble. Furthermore, this will for sure help companies who always ask questions about scalability of the Bubble.

Kudos to the team!


I cannot upvote this enough.

Bubble’s engineers have 18 months to help us get away from all the things WE have had to create to get round how THEIR inefficient way of handling certain things.

Please do.


Very clear, thanks :star_struck:

1 Like

Hi @emmanuel,

what about EU-based Amazon servers ? I thought this will be a part of this pricing update as well.



Yeh, a bit concerning. I’ve just looked at a really simple update I did on my database and it took 60k units for 500 records :neutral_face:


You are not alone, and I’m afraid that even optimizing and reducing by 30/40% the workload some apps are going to be rebuild on other platforms :man_shrugging:


I’m just gonna go all out and learn to code in the next 18 months and rebuild a much simpler version i think.


If you consider the workaround that bubble requires that may be a real option for apps that will be considered enterprise in the next 18 months.

Edit: there are workload-tiers to consider as well


Initially was hyped until I just realized my app used 22M workload units in the past month and the Growth plan only allows 250k. This will not be feasible for my app even with crazy amount of optimizations. If there aren’t some changes, I’ll be completely off of Bubble within the next 18 months.