Go for supabase or strapi. You can self-host and it is way cheaper.
Renato has mastered teaching Bubble so bad that he is teaching Bubble’s creators 
So it seems that the big issue you are trying to resolve is minimizing the subsidizing of the lower paying customers with the higher paying customers? Do you have a breakdown of what overhead costs are becoming a problem? What processes are really expensive for bubble to handle?
What cost more to bubble?
- App with 1 user and 1 million records being used.
- App with 10k users and 1k records being used.
It’s hard to understand the problem you’re trying to solve with out knowing the financials of your backend.
The big thing is making sure that there is profitable growth on both sides, yours and mine.
Plans
Free -Severely limited
Hobby - $6 /month - Max Database Things and Max Visitors.
Personal - $29/month - No max database. Limit of new things per month. (2K-3K)
Prosumer - $60/month - No max database. Limit of new things per month. (4K-6K)
Professional - $129/month - No max database. Limit of new things per month. (8K-12K)
Production - $320/month - No max database. Limit of new things per month. (50k) Overages get billed at determined rate only on the Production plan.
Something like this allows me to grow my business.
I would love some other user feedback on this.
UPDATE - The thing entries would not include users things. THIS IS A MUST for growth.
UPDATE - Overages could be billed at $1 per thousand over? Thoughts?
I think the general consensus is that if you are going to limit the database itself, that storage makes more sense than entries. I think that if you were to go with database items as your constraint it would have to be much, much higher. Like 10-20x. I actually think that entries would be harder for me to predict than storage. I can gauge storage based on real usage, but it seems fickle to try to gauge whether or not a user will do a repeated task that creates entries (even if tremendously lightweight entries). Regardless, I think there likely are some visualization tools your could build to be able to better predict when you would hit pricing tier caps. I think most of the capacity confusion occurs because what caused the capacity to max out isn’t directly pointed to. Improvements in the ‘Logs’ section in particular I think could clarify a lot of the ambiguity.
I under the sentiment on not charging using capacity… But I think that it still makes the most sense. If not, I would suggest storage over entries.
Disappointing business plan.
The solution is to look for another platform.
Disappointing business plan.
The solution is to look for another platform.
Why limit the database and accesses?
So far I don’t know of a platform that limits user access.
Now, limiting the database to rows of things was something that will force you to go to another platform or use the API to connect to an external database. This is until there are limitations in the API.
I’m disappointed in the Bubble. regrettable decision
OK, look at this from the other side.
If you had 100,000 users, they were actively using your system and liked it, then you couldn’t charge them one dollar a year to use it? You lose $.30 in transaction fees and you make $70,000.
So from bubbles perspective, this app could certainly sustain the new pricing.
Now I don’t agree with the new pricing counting things as that screws up well designed systems with many child records, but not all systems out there complaining about the new pricing model could generate $70,000 a year.
Yes, it allows you to grow your business, but 50k things per month on a $320 month it’s a joke.
Those numbers are still off. Since you’re still counting things, those number of things are way too low
In my opinion, the best way to approach this by charging for DB storage instead of DB things. Most bubble developers understand this concept and it is an industry standard. You can also have automatic add-ons to prevent apps getting shut-down.
For new users, you can also address this pain-point by creating a detailed guide or even a small free course? Perhaps a built-in feature that predicts storage growth (long-term solution) ?
Anything but DB things.
Also, just want to say I completely understand how difficult it must be to price bubble. It is, at the end of the day, an innovative solution that has to account for a lot different variables. The fact you are asking for feedback is a good sign and I’m sure everyone here wants bubble to succeed because we are all part of it. We all want it to be profitable & priced accordingly while still being the #1 solution in the industry out there.
I was getting vibes of this being set in stone, but glad you are considering other approaches.
I think this is a well thought out response. I still like database storage over new entries because it allows you to account for usage “spikes”, but I really like the cost breakdown and the prosumer plan.
To second @yusaney1 , I think that “new entries” isn’t the right approach because it limits apps with high additions to the database even if they are extremely lightweight.
That’s a valid viewpoint. But, of course, 100k users is wildly different than 100k paying users. It’s never that simple 
Rolling active users + DB storage into each plan makes each plan potentially not fit anybody. Some apps have LOTS OF USERS, little data. Others the opposite. Many inbetween. Having to pay for both means everybody’s paying for things they don’t need…
That would be very nice!!! I am starting my business, and I miss a simpler and cheaper plan. There is no problem paying more, but the price table vs limitations must be feasible.
I’m not sure how I feel about charging for new database entries.
I don’t think I like it, because it still incentivizes the entire community to optimize to create-as-little-data-as-possible. That’s bad for Bubble and bad for us.
If you really want to charge DB amount, it would be more convenient for Everyone to do it in a time frame (running year). Let’s say:
Personal plan - DB storage of up to 1,5 year
Professional - 2,5 year and etc.
In this way you, as a business, benefit that overall DB will be limited to certain amount.
We, as developers, can accumulate or aggregate certain values every year automatically as mostly they are needed for certain observations.
@emmanuel I’m thinking to PowerApps with SharePoint lists as db… MS limits complex query to work on a dataset of max 5k rows, while linear query can run on millions of items…
Understanding the concept was a bit difficult at the beginning, but now it’s easier and not very limiting… It’s like dynamo single table concept, you have to get the idea and then you have very few limits…
Another idea could be give to each plan a total capacity and show us in the editor, what each query consumes and is going to consume while data grows… Tricky, but doable working with historical data from aws…
However, I totally get why you need to monetize and to try not having “bad” app, but 5k records is really a no go…
Agreed. I modified my response to reflect that.
At what price point would make since in overages per month to you? 50k for $10
I think your pricing should mirror the pricing you have with AWS.
The RDS (if I remember correctly) Postgres db your are using is charged by a combination of read/writes and storage.
Storage (S3) is the same
Workflows (Lambda) is priced by number of invocations and runtime in seconds.
What about…
Free 1-100 active users, X GB database limit, high-end features disabled
$50 101-500 active users, XX GB database limit, a few more features
$150 501-1000 active users, XXX GB database limit, more features
$300 1000-2000 active users, NO GB database limit (unlimited), more features
$$ for more active users
$$ for certain premium features (i.e. features not even in highest tier)
The problem is you can’t just “wait it out” and “listen to the community” on this one.
Companies, businesses, agencies have to make decisions NOW to plan for the future of their applications and work. 2023 is not that far away. It’s less than 9 months. This isn’t something you announce, and then in six months reverse, after everyone has made alternative adjustments or moved to other platforms.
I feel betrayed and blindsided by this move and now am sort of dumbfounded on what to do next, but do know I need to make a decision ASAP on what’s my next move. Not months down the road with my fingers crossed hoping the decision is reversed.