Changes to how we charge for applications going forward

EDIT 3: 3/21/22 View the latest updates here: Pricing: continued discussion / community trust

and here: Pricing: the path forward from here

EDIT: see latest comment here: Changes to how we charge for applications going forward - #414

EDIT 2: see this update: Pricing change is on pause for now

Hello everyone,

Today, we’re excited to announce a change to our plans that will improve app performance and make our pricing easier to understand. On March 23, we’ll introduce a new set of plans that use a different set of metrics (at similar price points as current plans). Instead of primarily using capacity (which has proven to be hard for people to understand and predict), new plans will use the number of items/things in the database and monthly unique daily visitors, which is more in line with the industry. The base prices for Personal plans and Professional plans remain the same as today, and we’re significantly lowering the base price for Production plans.

While we think this new system will be better in general, we know pricing changes can be stressful, and we have come up with a set of rules to ensure current paid applications won’t see changes to their bills until the end of the year (but we very much recommend migrating). This post is fairly long: I’ll start by explaining why we’re making this change, then explain what the new plans will look like, and finally how things will work for existing applications.

Why we’re replacing capacity with two new metrics

Something we’ve heard over the years is confusion around what “capacity” entails. We originally introduced capacity in an effort to enable people to pay more as they scale. However, we’ve realized that it was very hard for our users to forecast and that, since people often didn’t know they could/should upgrade, applications would face downtime as they hit their limits. We also can’t count the number of times we received emails (or saw posts on this forum) from potential users asking “Which plan is right for me?” That in and of itself made us realize that our pricing approach wasn’t right.

With that feedback in mind, we sought to build a model that is clearer, easier to understand, and more predictable. After talking to many users (old and new) and looking at what our peers do, we found that monthly unique daily visitors and database things were much clearer to users and better aligned with how their apps scale on Bubble.

  • Monthly unique daily visitors represents the number of unique visitors that land on your app every day, summed over the calendar month. As an example, if the same user visits on three days, they count as 3 towards your monthly total; if the same user visits three times in one day, they count as 1 towards your monthly total.
  • Database things represent the number of things (rows) in your database.

The new set of plans

On March 23, 2022, in a week, we’ll introduce new plans and a new pricing page.

The fundamental idea behind these new plans is that they’ll offer much more capacity, with 15 units on Personal, 25 on Professional and 35 on Production (so that apps actually rarely hit their limits) and instead will have limits on their unique visitors and things in the database. We came up with these numbers by looking at existing usage data and took a generous approach that would allow most users to avoid hitting overages at their current volumes. If an application on the Free or Personal plan goes above its plan limits for monthly unique daily visitors or database things, there will be a grace period during which the application will keep functioning normally, until the app owner upgrades. Applications on Professional and Production plans will be able to go beyond their limits and will incur overage charges. Previously, with capacity, if you hit your limit, your app would become unavailable, and we recognize that for scaling businesses, a flexible model that can accommodate surges in traffic without interrupting service is much more appropriate, so we will now allow pay-as-you-go overages if you exceed plan limits.

To summarize this new approach:

  • Each plan will have a limit for the maximum number of monthly unique daily visitors and database things.
  • If you exceed this limit on a plan without overages, your app will continue working for a period of time, but we’ll ask you to upgrade to a higher tier plan, or to bring your usage back below the limits.
  • We will be sending emails and in-app notifications to users as they approach these limits on plans without overages.
  • Higher plans have overages available; they will be applied to invoices on a monthly basis.
  • For applications that go significantly higher than what Production plans offer, our sales team will be able to help you find a price that better suits your volume (applications would be hosted on the main cluster or a dedicated one).

These plans also respond to user feedback on a few other aspects of our pricing, specifically

  • We’re reducing the Production plan price from $529/month to $359/month on a monthly basis, as we’ve heard repeatedly that the gap between Professional and Production plans was too large.
  • We also are offering 4 collaborators on the new Professional plan (versus 2 on the old plan) to enable teams to iterate earlier and faster with more collaboration.
  • We’re significantly reducing the cost of additional storage, at $10/100GB (so 10 times cheaper than on current plans).

Moreover, we recognize that these metrics were difficult to track in the past. With the launch of this new system, you’ll be able to directly see your monthly unique daily visitors and database things on your App Plan page. As you consider the plan to which you’ll transition, we recommend cleaning up your database and optimizing your application.

How this impacts existing applications on current paid plans

Apps currently on a paid plan will be able to stay on that plan until January 1, 2023, or for yearly plans, until the end of their billing cycle, whichever comes later. That way, people will have time to assess which plan is best for them and potentially make changes to their applications (for instance, deleting database things that are no longer needed). That being said, we recommend that applications upgrade to the new system to take advantage of expanded capacity, and because that’s where we’ll invest going forward in terms of new features and performance improvements. Practically, here is what will happen for applications created before March 23, 2022.

For three months, from March 23, 2022 to June 23, 2022

  • Existing paid applications can switch between legacy paid plans and/or convert to yearly legacy plans (without usage metering).
  • Existing applications on the Free plan will not see their monthly unique daily visitors limit enforced, so that people have time to adjust and understand what plan is right for them.

After June 23, 2022

  • Without any action from the owner, legacy paid apps stay on their plan until the end of the year (or the next yearly billing cycle, whichever comes later).
  • All apps can only switch to new pricing plans (legacy pricing plans will then be unavailable to select).

We value the trust that you’ve placed in us by building your app on Bubble, and we want to make sure this pricing change works out for everyone. We are confident that for the vast majority of applications, this change is beneficial and will lead to clearer, more predictable pricing as your application scales up. That said, we are aware that there are some applications that have an unusually high ratio of database things or monthly unique daily visitors to capacity usage and would end up paying significantly more on the new pricing. If you fall into this category, we’ll be reaching out to you over the coming months to discuss your situation and find a way to make sure you are able to continue using Bubble. You’re also welcome to reach out to us at at any time.

We’re incredibly grateful for your support over the years, and we’re looking forward to supporting your journey as you scale on Bubble for many years ahead!

Emmanuel & Josh


Hey @emmanuel

Have you evaluated well the database records number? I mean for professional just 25.000? It’s super low.


Will free plans still not be able to connect to custom domains?


Hi @emmanuel and @josh !

Thanks for the detailed explanation.

I assume that the “Database things” is the total lines of all our tables. If so, I think it’s too low!

“Delete the records or clean database” it is not a doable things as we need to store the history of what is going on.

Limiting the numbers of lines in the database will force every small app to migrate to larger plans over the years, as it is expected that the database gets bigger over the time.

If I understood right, this was the worst news I read here. So sad to know that even with my small app I will be forced to move to more expensive plans just because of my database.

5k and 25k is super ultra mega low.



This is going to ruin my business…


I’m with you it’s super low. Due to the limitations Bubble has that we need to touch the database for everything it scared me a lot.

And because of the Bubble limitations you’ll go over the production quite fast.

And yes, worst news ever in Bubble.


I’d like to extend what @rpetribu said about the database things being low by giving a practical example from my app. I have an app like Airbnb with listings, and we track the number of views that each listing has gotten as a unique record in a data type called “Listing Views”, so that means that every time a user lands on a listing page, we record a unique entry, so that we can then tell the listing owner how many times their listing was viewed in the last 24 hours, 7 days, 30 days, etc. We need to store these unique entries so that they can be broken down by date.

So you can have a situation where your application has 20 data types, and 19 out of 20 of those data types can have a relatively low number of things, but in terms of this LIsting Views data type, as of right now we have 90,000 things for listing views, but every other data type has below 5,000. This is because we have a relatively decent number of users coming to our app from google organic search (aroune 6,000 monthly, which is still within the range of the daily active users metric), but because we want to track these listings views line by line, a lot of these users could end up looking at our listing pages but not converting into customers.

I do concede that doing this blows up our database for one data type, and we can look at more efficient ways of doing it, and I am happy to upgrade from our existing professional plan to production in terms of the cost, but with this new pricing we’re in a situation where, as of this moment, if we get another 50,000 listing views, we’ll hit the 200,000 database things on the production plan specifically because we track a certain type of data in a certain way. Yes we can afford it, and yes we’ll have more customers, but I feel that this database things limit is going to fundamentally alter how we track our data for our application.

We are happy to look at new ways of doing things, totally understand that part of this is to get developers to build apps efficiently and reduce the stress on the system, but I feel that there’s going to be a lot of cases going forward where people are going to get stressed with making sure their database doesn’t hit a certain limit, which could fundamentally alter the way their build their apps.

So my suggestio off of this would be, if you guys actually cut in half the monthly unique daily visits as a consolation for getting rid of the databse things, that would be very helpful. Also, perhaps an idea is instead of making just text-based database things count towards the limit, perhaps only have ones that contain media that actually take up space count towards the limit.

Lastly, I also haven’t yet really seen what the overages are for database things, so if this is just a function of adding another 200,000 database things and it’s something like 10-15 dollars a month in overage, then that wouldn’t be so much of a problem, time will tell.

Thank you for the consideration!


Agree with posters above. This is a really dramatic reversal – going from unlimited data rows to low limits – and pulls the rug out from under a lot of users (including myself).

The new database limits effectively torpedo Bubble’s effectiveness for a database driven app and will force users to start looking for other solutions.


But what does it mean? New database records per month?


I saw it too. But that is not what @emmanuel said:

And in the image showing the price of the plans, we can’t see the word “Montly” before “Database things”:


The changes make sense to understand capacity, however, the database limit is very low and I will have to redesign my newest app with more complex solutions which will make it less No Codey.

Might it be better to have it be based on DB transactions or database workflow actions rather than ‘things’?


This has to be ‘new records per month’. But even if it is that is a low number, especially if people have Logs or Activity data - because the Bubble log are often unhelpful and not available to be shown to end users. This already would be at least a single Data item per unique visitor.

As a Bubble Developer I feel this also limits creativity and wanting to use Bubble for the exact CRUD functionality that it is so good at. Instead I would only really want to use Bubble for apps that are Read Only data which other app builders might actually be better/more performant for. I feel like it counters one of Bubble’s best selling features - ease to create and manipulate Data

But a serious question that might solve this - how many rows of data (text only fields, 20 columns) would I get for if I paid $10 for 100 GB?


Seriously, we understood something wrong. Almost every app will have to migrate to Professional. It is impossible to maintain an app with just 5k rows in database. This is ridiculous. I will have to move from Personal to Production and pay 10 times more than I am already paying.


It seams like they´re becoming a no database frontend app builder.


It would be fascinating (to me, at least) to know what Emmanuel and the product team do right after they pull the trigger on a post like this one. I assume they brace for impact in some way, shape, or form. For folks who talk about the forum being dead these days, well, this post will certainly liven things up.

For what it’s worth, I agree with others that the number of database things seems way too low.



Where I work we’ve been using the same web app for 8 years. While there is only a dozen user accessing it we must have well over 500k records overall. That would be 3x more than the production plan which does not make sens…

I’m pretty sure the number of records represent the “trafic”; database transaction per month


+1 DB limit is too low


Thank you for the update and transparency as usual.

Some thoughts from me:

  • I’m confused about what exactly “database records” entails. Your post seems to say that the Professional plan offers a total of 25 000 records saved in the database (which I agree is extremely low) but your screen uses the term “Monthly database records”. What exactly does that mean? The screenshot also shows (Monthly database records overages), which could suggest that you calculate an average of the total number of records stored over a month (as records are added and deleted).
    If this means an app on a Professional plan supports an average totalling 25 000 records across all Data Types then this is a drastic limitation that I don’t think will be well received. This will have a major impact on how apps are designed from now on. Maybe this was your intention, but I’m still caught off guard at just how low this is.
  • Your screenshot also suggests that you can pay a smaller amount per month to increase the database limitation without upgrading, or is this to be understood purely as a temporary “penalty” before upgrading your plan?

  • How does this affect features that are bound to specific plans (such as versioning, sub-apps, backup times, etc)


:rofl: that DB limit is surprisingly low

So, if anyone needs help using an external DB, I’d love to chat to get you a discount on Xano plans or even to harness Firebase/Firestore!


The email is poor. You consistently say that it is a similar or lower price point and yet the way you have had the pricing means that a lot of users will have invested into database heavy apps and now this is effectively a rug pull. Nothing has gotten cheaper so I don’t understand the ‘lower price point’ in the emails, there is only the potential for costs to increase massively with this. Is the database things monthly or what? That is a big point that needs an answer.


We seem to have revived the forum at least :sweat_smile: