Can the bubble team comment on the overage cost?
Is it actually $20/mo per 5k rows?
Charging rows logic:
App 1:
Database: 1 row x 1 column
Data stored: 1
Price: $
App 2:
Database: 1 row x 100 MM columnns
Data stored: 100.000.000
Price: $
Make sense 
5 Likes
yes database storage is easier to predict. I know for instance my database will not explode to 20GB tomorrow or in the next 3 months. it is quite linear the growth and I could delete certain things.
(Our production app plan runs around 30k workflows per day.)
However, the amount of rows is super hard to adapt to. Same with visitors. You have high months you have low months but now you definitely cannot spend 2k on marketing and see what sticks (or just save emails/signups) as your costs will go up considerably.
9 Likes
If I had to choose, I would stay where we are. Our apps almost never go above 5% capacity unless we are doing maintenance works, but we have +300k items, but I understand that this may not be sustainable for bubble. Would the following work?
- Monthy active users +
- Monthly new records created +
- Maximim db storage
That could work for our SaaS app.
Everyone to firebase or cloud at this point
1 Like
Thanks for showing great leadership Emmanuel by listening to your users and being transparent about your reasoning. With this attitude I am sure your company and user base can arrive at a mutually satisfying decision.
1 Like
I will admit I have not read this long thread, growing by leaps and bounds on its first day.
In my database design, while I may end up with several thousand users, they are infrequent users, or users that are mainly on for a yearly or twice a year event. They sign in and browse data for our event.
I only have 800 main records (like bnb listings that someone mentioned in their app). But theyâre allowed to mark/favorite data records. So thousands of users, which are gonna have several favorites each, already makes me get close to a limit.
So while I may have many things, those things are not affecting storage, as a many 2 many record generally doesnât hold a lot of data. Itâs just some pointers. And itâs not a big load on the system either, as that user isnât gonna come back for another six months or another year until the next function, and we wanted them to have access to the notes and items that they created on their prior visit.
I understand youâre trying to make changes based on metrics of existing apps, but this change makes me I have to totally re-design my schema and functionality just to stay under a significant price point.
Or move to another tool.
On the pricing suggestion bit:
I like the 60usd prouser idea someone mentioned on this thread. It makes sense for companies like ours which dont need a 150usd plan and are little to big for a 30usd plan.
1 Like
What about just daily active users as the primary usage metrics?
Segment, for example, does this and has done quite well.
In addition, charge for additional features that add noteale distinct value. An example of this which is rather extreme but I feel still within reason is Honeycommb: Honeycommb Pricing - Full Suite
A bit of derision in all this anger. This is how I see Bubbleâs forum right now.
17 Likes
Ok @emmanuel Iâll start studying how externalize the DB via Xano or Firebase as I have no better alternative. This will be a big investment in time and a layer of complexity.
Can you guarantee that API calls will not be restricted in the future? For how long? Without such a commitment, it becomes very risky to make an investment today. Thx
8 Likes
Whatâs the difference between having a limitation in the database or having the limitation of how many entries you can create per month?
Much better response 
I fully understand that you have users that pay you barely anything, but have very high usage so âonlyâ monthly unique daily visitors wouldnât work for Bubble as a business. The âno limitâ on databases is the biggest selling point you have but I do agree with moving away from capacity CPU usage as Bubble already want to do; if I worked for Bubble. Thatâs what you want to do and thatâs definitely okay.
Iâd prefer database storage over database rows; having a limit on database rows destroys Bubble for what it is; itâs Bubbleâs selling point. Itâs the reason I joined Bubble. Iâm not quite sure what metric you could use but I think I can speak for everybody when I say please remove the database rows limit on plans. Anything but that.
2 Likes
LOLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL 
I needed a good laugh amongst all of this. Thank you for this!
We needed that!!!
Personally, I donât have a problem with an increase in price, but the database entry limit model just doesnât work.
It also incentivizes bad DB design:
Instead of building out multiple data types like a typical, high-performance relational database, builders will now be incentivized to:
- Have a User
- Fit everything else into âContentâ
to minimize the # of database rows. Obviously, this is only going to make logic harder to write, search queries messier, apps harder to organize and less performant. It is very disappointing to see @bubble try and disguise this move as an attempt to increase performance.
Having to connect to an external database for every app that exceeds 20k-200k database entries just simply eliminates most of bubbleâs appeal, as already echoed in this thread. Itâll also have a substantial impact on agencies and experienced freelancers, who will now need to connect to an external DB and teach it to their clients every single time. Itâll also significantly decrease the number of interested business owners willing to build their first web/mobile app on bubble.
I think it is better to calculate a per-unit cost of maintaining 1MB of database storage, and create a pricing model based on that. Youâll be able to charge the heavy databases, disincentivize bad DB design, make @bubble more money, and make apps more performant in the long run.
6 Likes
I would love to see things priced similarly to how they are now. But with the ability to add things on that improve the experience and output of our efforts. Here are some off the top of my head:
- Pricing for Scheduled vs Real-time Rollouts
- Pricing for added collaborators or by seat
- Pricing for Additional Tools and Built in functions like the way âMembershipsâ are being rolled out on Webflow.
- Pricing for added capacity & uptime
- Pricing for Powerful integrations like Algolia.
- Pricing for better subdomain support.
- Pricing for Pre-Render vs Real-time Rendering
- Pricing for better CPU on data manipulations
6 Likes
The limitation on the database relates to the total amount of records you have in (GB) and the total amount of items created per month, well it defines itself. The first item should we relatively cheap, compared to other solutions in the market.