I guarantee this idea came from their new VCs.
Out. of. touch.
External data is certainly possible but its not a small job to re-write an app to use a different data source once you re-factor and test.
Iâve said this multiple times already so forgive me, but cost plus pricing is bad.
Best pricing, for all, is value-based. I think Bubble is trying to figure that out, and they missed with this last attempt for sure. But value-based pricing is the way to go.
Donât even think of building an app with the simplest âsocialâ features like messenger, comments and replies etcâŚ
This number of lines in DB is a joke. This is also disappointing.
I suggest you roll this back before you kill the incredible tool and community you have built around those last years.
Another example of a company that raises too much money and forgets where it comes fromâŚ
Fully agree. The move away from current âcapacityâ is huge.
Iâve never used Xano, but you can still send an updated random string to the Api call that doesnât break the call. Probably the page refresh problem will go away.
Thanks for touching base. I totally appreciate the need to make money from customers making lots of money by using bubble, and that nailing that metric can be tough.
I would personally much rather see DB costs scaling with disk size rather than database items, as that doesnât penalize architecture choices as much, and also is way more comparable to other services, so we know the costs will be pretty standard.
What if the primary incentive to increase tier was reliability and admin tools, if you make big money then itâs easy to pay for that. I donât mind monthly unique viewers so much, as I think that generally scales with customer revenue, but DB entries seems crazy, and Bubble doesnât even pretend to have any database management tools for large databasesâŚ
If people are using Stripe to charge customers, perhaps take a small piece of that?
Yes, Iâm doing that when creating a new record 
I donât know, MAU or DAU count seems to be a pricing metric that some highly successful startups use. Question isnât really whatâs the perfect metric - but whatâs the better one?
Great to hear such a rapid response⌠Really a relief!
- I Think Bubble is cheap and there is room for price discussionâŚ
- You take care of the heart of our business, so, trust is a must!
- You should be a plataform that stimulates more and more no codders (so, price matters);
- I donât think as a MVP plataform⌠Legacy is a real problem, and you take care of itâŚ
Difficult to think as founder, depends on your goals⌠increase bubblers, increase incomeâŚ
But smthg is clear to meâŚ
- DB must be cheap - it is cheap everywhere;
- Iâd to pay per performance ( as I think it is now) - If I grow, I need more scability, so pay more is a good deal;
Something based on âamout of server requestsâ could be a wayâŚ
A more reasonable approach. @emmanuel
This is the most accurate and well thought out response to the changes from a customer perspective. It would be better for Bubble to back peddle this and at least offer some way for unlimited entries. Or be transparent and say hey there are too many database entries and its not working for our business model and use someone else for data storage. Just let us know if the business model doesnât work on the data side and you may find there is much more community support for the transparency.
Totally.
The combined value of everything on offer means that we donât just get to pay for the raw materials plus a bit.
The challenge is finding a fair and simple common denominator that doesnât create weird incentives (like taking your db + backend somewhere else). But to avoid hugely complicated PAYG structures we have to make peace with that proxy metric thing carrying the rest of the value that the platform brings too.
Yes, the simple math that an app could increase in cost by 30x is telling.
At a minimum, whatever Bubble would do for those edge cases should be figured out before an announcement like this!
Eager to see what further info we can getâŚ
Oh, I didnât mean they should implement a 1:1 cost based pricing, simply put I believe the price should reflect actual usage.
As data is extremely cheap to store (and 25K rows is laughable, at most 10-20Mb of data), this is the wrong dimension to focus on for bubble.
Some apps a file heavy, others database heavy and some again are workflow heavy. A fair price for everybody is that the price follows how many resources is consumed.
This was basically the idea I had. DB capacity makes more sense than records or server capacity if you want to use the database as a price factor. Itâs easier to understand up front and at scale and gives users a better idea of what to expect as they build and test their apps.
Yes, and it can be possible to have a mix of a PAYG metric, plus subscription tiers or premium features.
But the more you squeeze everything into pre-set bundles, the fewer people each bundle will work for.
And, you donât want your pricing to be overly complicated.
Lots of catch 22s and creative tensionsâŚ!
Hi @emmanuel,
We store historical changes for things in our database by creating [thing]_backup tables.
Each time a field is changed, a new row is created.
Itâs essential for our internal apps for security reasons, and itâs not done natively by Bubble so we have to use this workaround.
We have hundreds of thousands of lines like that (~880k at the moment), even if we mainly use ~60k rows 99,99% of the time (the ones that are not for backup).
This update on pricing is a nightmare for us.
Please tell us how to deal with that.
Should we externalize this part to AWS database?
Bring back pushing to live with free plans and youâll redeem yourself
I hear what youâre saying, but value-based pricing says otherwise.
Value-based pricing means aligning pricing with the value a customer is able to derive from an application or product. Of course itâs impossible to derive value, precisely (unless youâre in fintech and you can just charge a transaction fee, but even then thatâs not a pure reflection of Stripeâs value).
But the closer you get, the better. That means some usage (most usage) will always go to your overhead, while other usage you may meter and charge for.
Value-based is always the way to go though, because it allows users to pay in line with the value they are receiving, and Bubble to derive the most fair revenue from the product.