I agree we need permanence here, for sure. As much as possible.
Unfortunately the feeling of stability only returns with time. I.e. stability over time.
What a catch !!
On our brazilian whatsapp group as well. And we are 25% of Bubbleās total user base.
So whatās the point of using this metric to base your pricing ? If you, as others, keep this metric, all creators have to arbitrate whether or not they can monetize each visit in accordance with their business model, which is total nonsense for many web apps and for you, as you said.
An effective price, in my opinion, would be the one that takes into account the needs in terms of performance and/or features. Capacity, storage, number of editorsā¦ the same ālogicā as today actually ! āFree to learn and build. Pay as you grow.ā is on your pricing page. Pricing should allow creators to forecast expenses and should fit their business model which is not the same all the time and is different for each web application. So the resources needed are good metrics to base it on. Finally, it allows Bubble to scale any type of web application, like its tool does.
So at 150k entries added a moth, on my suggested production plan is around $0.003 per entry. To hit the price you are already hitting.
this becomes unsustainable for many apps for example who are creating social networks. I donāt think it solves it, but a partnership with AWS and passing on the costs to us would be very viable.
We did! A lot!! Itās opaque, itās not really more actual CPU load (but a calculation of āserver timeā), itās extremely limiting for large- and even medium-scale data workā¦ Itās a huge problem IMO.
This is incredibly well put.
This is concerning and honestly feels like a yoke, how are we going to explain this to clients? Nobody in their sane mind will build a custom application from scratch with a limit of 5,000 āthingsā.
Letās examine a simple booking application.
- Booking application with an average of 2 bookings per day and 100 shops connected. That means the database will be populating on average 200 things per day and on average 6000 things per month. By the end of the year we would have approx 72,000 things in the database. This modal assumes we only have one data type, seperating data types will only generate more things, letās say we have another data type that simply just store the images for these data types, we now have 144,000 records that are generated on a yearly basis. Weāll be paying Bubble on approx $1400 per month. If the average booking is at 10 bookings per day, weāll be paying bubble approx $6,000 per month. 9 years later and weāll be paying an average of $18,000 per month.
If my calculations are incorrect, let me know and Iāll adjust it.
Now instead of limiting to things, instead you can limit to the size of the database tables?
DB storage + unique users would do great!
All this nitty-gritty is fascinating, but here are the underlying issues:
-
You have a lot of funding and a lot more advisors than before, presumably. Why wouldnāt your additional strategic and operational capacity result in some real user research with a restricted group of beta/power users that represent a range of different use cases and application ābackendā (DB schema +workflows) designs? Why make some guesses, make an announcement, and then have all this blowback. It happened before ā didnāt you learn from that? Donāt use a focus group like this, after the fact.
-
As one commenter said: what is the problem YOU need to solve, Bubble? How much does each row/thing cost YOU? Pass that on to us, by all means, but this just seems like it is using the row as a (BAD) proxy for your real costs. If your previous system, based on an algorithm that takes a bunch of usage inputs to form Capacity was actually covering your costs with a good markup, then it was better! I hope you didnāt let one of those VC/advisor types who just blurt out what they ālearnedā from their ONE (randomly) successful business and run with that. You are operating a very different type of business, with very different customers than almost ANY OTHER BUSINESS. YOU @emmanuel and @josh know your customers better than anyone. Strategize like it. Tell your board to shut up and leave it to you. If they didnāt believe in your judgment, they shouldnāt have invested.
(Or just tell me if Iām way off base with this scenario of you getting bad advice.)
Thanks for your HARD work building this incredible product that has enabled me to pursue some dreams I didnāt even know I had.
Fred
Yeah great question! Iām really not sure what features to include or not. Point being: There is an opportunity for gating more features, IMO.
In terms of users, sure, those were rough #'s!
Database things is certainly a bad idea. If for no other thing than that it will skew database design in unhealthy directions because a simple decision to create a secondary table which will have 1000 small rows will have eaten up a significant part of your database allotment.
This makes no sense. Space is a much better metric, for more imprecise that it might be, as adding smaller tables and records which might be good for application design and performance will not significantly affect that.
There needs to be away to have a pricing model that is simultaneously fair to bubble and to bubble users. I believe it is only fair for users to pay for what they use, be in terms of processing capacity, storage utilization, network bandwidth and so on. I submit therefore that the best thing would be to have plans with sensible starting costs that gives the user a known price for their starting costs and provide clear steps going forward. At the same time, there should be overages available for the users whose needs donāt go far enough to warrant the jump to the next plan tier.
This would allow for a paced approach to cost increases as application usage increases, while providing a path for those that want a simpler cost structure to simply upgrade to the next plan, and possibly get a discount in relation to the eventual overages that they would have paid by going the āon demandā route. Bubble gets more predictable revenue from those choose to upgrade instead of paying overages in the lower tier, and those customers get a better deal on that ācapacityā.
These could include simultaneous users, monthly users, database storage allocation, processing units, etc. This sort of approach is the only one that ensures that a user pays for what he is using and doesnāt freeload on those that do (or on bubble). An application with few users but a ton of processing will pay processing overages, but no user-related ones. Another application that has a very small database but which attracts millions of users will pay for user/bandwidth overage, but not for storage and processing.
The most important thing in such a pricing scheme is to have clear and well-defined tiers for those that donāt need to worry about counting pennies, but that allows those that do need to count them, to do so.
Salut ! Jāaimerai bien participerā¦ Pouvez-vous māinviter svp?
First of all let me say, Bubble is an incredible thing, it truly is something I never thought would or even could be developed. Itās a work of genius and the founders deserve all praise and reward for what theyāve achieved and the way theyāve done it. Iāve never bought into a lot of the petty criticism Iāve read on here in the past, a lot of which I thought demoed a lot of naivety and, in worst cases, an unwarranted sense of entitlement and I have oft leapt to Bubbleās defence. However this is something completely different.
I am just glad that Emmanuel and Josh are seriously considering changing it based on the furore on here today. I donāt think Iām overstating it when I say that if they do stick with this, it will more than likely kill Bubble in terms of momentum and leadership position in the no-code arena. It would be an act of monumental self-sabotage. Certainly back in Nov 19 when I discovered Bubble, if Iād read such a severe limit on database records, I wouldnāt have gotten passed the Pricing page which would have made my life a lot poorer in these intervening years.
While it took me over 2 years to fully throw myself into Bubble, Iām now fully invested, thrown my career into the Bubble cart, rebuilding large scale apps from code to no-code, my days have been joyous, Iāve been loving life, certain of Bubbleās future and their willingness to go to bat for indie app devs who want to build the next gen of SaaS apps. And then this!
I actually donāt mind a limit on database records as a metric for price plans but it has to be somewhere in the region of 10X the level thatās been announced. I simply cannot be put in a position where I could be nickel-and-diming my customers for every record and transaction they record, it just isnāt a viable business model and would end up pricing my app out of the market.
A better metric is the number of active unique users as, for SaaS customers like me, Iām paying for the number of users that Iām getting paid for. Other alternatives would be the number of reads and writes with a generous base limit as Firebase do.
Itās also worth pointing out a double-whammy with this. I like & implement @petter 's approach from his book about Bubble performance, due to lack of SQL joins etc, is to optimise for reads over writes to improve performance by creating satellite types/tables and duplicate data where required. With database triggers etc this works but does involve a situation where data can be duplicated in several places - which exacerbates the problem with the tiny limits being introduced.
Honestly if I thought you were gonna stick with this, Iād be deeply upset for myself considering the investment in time and energy that Iāve put into Bubble and for Bubble itself which will be severely damaged by it. Iād be online tomorrow looking at Supabase, Xano, Firebase etc. I hope youāll give us a glimmer of hope that I wonāt need to.
I know most of what Iāve said has already been shared by others but I thought Iād add my voice to it so that you can truly see the problems this would cause for us devs who have thrown our lot in with Bubble never believing for one minute that we would be put in this position.
Thanks.
why not think of price according to the userās choice?
Example:
- I need more database space, so I would have: $1/5Gb, $10/100Gb, $20/300Gb
- I need more visitor traffic so I would have: $10/1k daily, $20/3k daily, $50/60k daily
- I need more processing power, so I would have: $10/1 unit, $20/3 unit, $50/7 unit
It would be a price calculator, prices would no longer be FIXED. This is how it is for example with multiple servers.
In this way, your user defines the best amount to be paid while his application is scaling.
I want to pay Bubble $1,000 a month, $5,000 a month and even more while Iām growing too, but that will only be possible with fair pricing.
Weāve been here for so long, so much learningā¦ throwing a lot of peopleās dreams in the trash, making promising projects unfeasible is not the way out.
While it may have been challenging for some users to project their costs charging based on capacity/usage is the fairest way to charge. Usage has a direct relationship to value realized by us, the Bubble customer. If our app performed an activity, we should be charged. If you need to raise prices on storage, assuming justifiable to market rates, that also makes sense. What does not make sense is to charge for potential usage. If an app has 500,000 records, but only 1000 are accessed on a given day, we would now be charged for potential and not actual use. Certainly, there is some value to us for this potential, but these new plans do not treat potential use any different than actual use. Storage charges seemed to handle this previously, but if a different model is needed this seems to be a model that disincentivizes growth. If this is truly being driven by customer request to reduce confusion to the population of customers having issues with the capacity charges, why not just add these new plans as options rather than replacing the existing options? Bubble can offer plans that are capacity priced OR record count based. In either, you can certainly build in acceptable limits and overage fees. This way Bubble is not alienating the developers and apps that have been on the platform for years and made their choices based on a pricing structure that is now being completely changed on an alternative axis. As a comparison, if we look at AWS, Azure, and Google Cloud databases none charge based on the count of records. If there is a population of Bubble users that do not understand capacity charges, then please donāt penalize those users that have no issue with capacity/consumption pricing.
If Bubble cannot come to a viable consumption/storage based pricing model, at the least, please eliminate these seemingly arbitrary db item levels. Instead make the db pricing purely per record based. I have no idea what an actual market rate would be, but if, as an example, as developers we know pricing is .000015 per record (again, purely a fabricated value), then Bubble can earn an appropriate fee for high record count apps without requiring a Bubble user to jump from Personal to Professional to Production plans for an app that has minimal capacity needs.
Complicado essa postura !
Clearly weāll have a big trouble to maintenance of our applications in this new price formatā¦ Itās absolutely insane and non default. Please, rethink that.
Thanks @renatoasse you represent me!
I just think that putting any limitation for records in the database is quite complicatedā¦