Changes to how we charge for applications going forward

Gonna start eating our words! However, that does make sense @julienallard1

1 Like

I know you guys are evaluating this based on average stats across your customers, but you can’t make decisions based on averages. For the people that are on the extreme end for one reason or another, this is a gutting decision.

I have a client with ~300,000 database things that doesn’t require much processing power but does need the ability to store this info. It’s not just activity logs, but actual VITAL information for how the app works.

We’d be going from professional to above production with this decision.

This will seriously harm profitability for a lot of people.

Again, decisions can’t be made solely on averages. Please also consider people who legitimately need larger databases but don’t make absolutely bank doing so.


Dedicated plan was for this purpose I suppose ;


I would be using an app with well over 1 million records, where does this stand to be priced per month?

Will you improve the process of being able to batch delete old records or make it next to impossible to do this, forcing users to upgrade more often?


Lol, I know right?! I’m trying to reading and get bumped out :rofl:

1 Like

Since API calls are free… anyone out there offering Bubbe DB as a Service?


Looking at the absurdly low database limits on these new plans, this is going to be a disasterous change that will seriously impact loyal users and advocates of the platform.

I hope there is going to be a change of decision on this, the database records need to increase 10x to make this work in any way.


That goona force us to upgrade


Clearly, batch deleting records is just impossible at the moment. How are we supposed to keep monthly prices low if this feature is not available ?


:running_man: :running_woman: Bubblers on their way to check out Xano and Backendless.


I am an absolute fan of Bubble,
but here it is VERY DISAPPOINTING !!! notably about the ultra low limits …
We understand the logic behind this, but we feel a little bit trapped now that a huge number of bubble apps are developped and sold and running …

1/ We shoud have no impact on already paid plans (very hard to manage with existing customers not to say impossible)

2/ And we shoud have limits yes, but much much bigger limits

Thanks in advance for your understanding


Speaking broadly, I applaud Bubble for the significant work, long-term thinking, and grit it takes for this kind of change. Every startup goes through big and painful evolutions, especially with $100m in funding. To not evolve means death. Thank you for your commitment to evolving.

Lots of valid concerns on the thread that deserve attention. I’m eager to hear from app owners that would stay within these limits - what do you think of these changes?

Second, @emmanuel @grace.hong etc., maybe it’s possible Bubble is too powerful for the database limits to have its intended effects. Bubble itself could be used to work around these limits 100s of different ways (more fields on things, JSON, etc.) that would avoid overage fees AND add overhead to Bubble itself (heaver processing).

So I’m very curious, why did you decide on things as opposed to database size such as GB? (obviously “things” are a simpler metric, but your user base is, ahem, quite sophisticated :slight_smile:)


This is a bad call. These database limits are prohibitively low. This will be the final straw that makes a critical mass of us start looking at platform migration.


So you guys just want us to find external DB solutions with this pricing, which will kill your platform in time, as integrated DB was one of your core competencies.


It just has to be calculated on the added database things in a month.
Total has so many negativ consequences such as:

  • People will design database structure for saving things, not for effectiveness
  • people will use bubble as a Front-End Builder and connect to external databases via API’s.
  • People will leave bubble or just don’t use it, cause they know that when scaling their app, it basically becomes not payable → Imagine a app with thousand of users creating thousands of things. You would basically have to upgrade every month, if its total records.
  • People will start using backend-flows to delete things, to stay in a tier → With some data you are not allowed to delete it and have to store it for several years → Bubble will not work.
  • People will delete inactive users, because they use up things in a DB → No reactivation of a user

all in all just a bad idea :frowning:


:sob: that seriously hurts my future plans with bubble…


Hello @grace.hong thank you for your update - so I can understand it better, the database row item limit, is it based on all row entries or is it based on active row entries, I.e. entries created, deleted, or changed?


I am here to help with all external DB needs! :slight_smile:

Let’s get our API engines fired up. Then when they cap that, we’ll revert to JS. then when they throttle that. Turn to weWeb!


This reminds me of some company that was selling lifetime licenses. After grabbing a good amount of users, they started to revoke the licenses forcing everyone to change to their new monthly expensive pricing plan.

I think this will benefit only large apps, where small apps with large databases will be forced to use a high-tier plan because of only the database limits and not because of the app’s needs.

After everyone moves their databases outside Bubble, will we see API rate limitations in one year? To make sure everyone it’s forced to use bubble databases again?

And how is the average calculated? With the total apps? I have tens of apps that have insignificant databases, are those included in the average?


It sure pulls the rug out from under me.