Thanks for the clarification. In our case, we absolutely see that we can optimize greatly in some of our applications - awesome.
Could you please elaborate in your post on the possiblities of backup? This is very important to us. From your collegues, we understood that:
Starter pack will be 2 days
Growth pack will be 14 days
Teams pack will be 20 days
Our current applications are all on Starter and Professional, with 14 and 30 days backup relatively. We can not sell a 2 day backup to our clients, that is unacceptable. And as it is for now, apparently we canât do anything about it.
Looking forward to hearing from you soon, thanks in advance!
How can they make decisions on AVERAGES !!!
Awwwh ⌠please hire a better team who can understand how to evaluate Data, segment and then tries to understand the JTBD (Jobs to be Done) and then see how any kind of pricing would effect scaling.
OR at least just learn from AWS & the rest and donât try to invest new pricing models which will end Bubble as the #1 platform and just do Capacity plus pricing (not capacity + 100000% profit pricing)
@tatiana.a, see gaimeds response in this topic and his measurements in the announcement topic yesterday. The numbers you mentioned are different from the actual numbers in the apps, your comments?
#Bubble never more!!!
Today I use 2% of server capacity and 10% of disk storage. With this informations, it is clear that my app isnât a problem for BubbleâŚ
BUT, with the new pricing proposal I will pay almost US$600 (today US$29) per month. Itâs ridiculous!!! Someone could explain what is the logic on this Pricing??? If my app demands only 2% of server, and 10% storage, will 20x pricing increase??? After the catastrophe of 1st round pricing discussion, now we have the 2nd round pricing discussion #Bubble never more
I wanna reiterate that most of the high usage (including my own) is before any optimization.
We havenât seen a before & after result yet. I could be at 3M right now and that could be brought significantly down after optimizing / figuring out whatâs causing the high usage
When we talk about the cost of database operations on Bubble, take a peek at Xanoâs pricing. I know weâre comparing apples and oranges here, but you get unlimited database rows (throwback to Bubble attempting to price on records), unlimited operations on your database, unlimited API calls, and nearly unlimited Lambda functions. All for $59 a month.
The amount of profit Bubble will be making on Workload Units has to be astronomical.
Quote from Bubble pricing announcement: "Predictability: Weâve designed our pricing plans so that most apps will not need more workload than whatâs included."
Can we see the data that shows how you guys went through the design process of the new pricing plan?
Either itâs a false and misleading statement or complete bs, if itâs true - please provide us the data showing that most apps are currently within these WU limits.
All my current apps are using millions of WUs and Iâll be shutting them down within 18 months.
With the motto of no-code being there to empower people, I feel like with the current pricing tiers and WU costings, its actually now more limiting than ever before.
Prior there was many ways to do 1 thing, now it becomes 1 set way to do something as efficiently as possible, not just in the bounds of getting the speed/performance and reliability within Bubbleâs framework, but also now to not incur a heavily pricey outcome. Goodbye to thinking outside of the box and fancy workarounds.
Iâve been here since 2015, the time has come to move along.
As much as I have enjoyed my time here, Iâm ready for a new adventure. Iâm leaving with happy memories of the people, projects and experiences that have shaped my time here. I know Iâm taking away skills, knowledge and confidence that will help me wherever Iâm headed. I wish everyone here ongoing success and happiness.
No it can not. According to Bubbleâs own findings, most impacted apps can see a 30-40% reduction. And thatâs with the people who knows the ins and outs of the system⌠not you. So letâs be nice here and assume you can achieve the 30%⌠youâll still be looking at 2,100,000 WU⌠nowhere near the included amount in the plans. Itâs ridiculous, please donât pretend this is in any way defendable.
The Workload usage is pretty straightforward. You get charged for most interactions in both the development and live version. Such as: workflows, page loads, api calls, uploads, and fetching data.
In theory it would be possible to map out the workload usage for workflows, api calls, fetching, etc. However, it is near impossible to predict user behavior such as:
how many times will they load a page.
how many times will they add or change data.
how many times will a workflow be triggered.
how many times will a filter be applied or a search be conducted
With these unknown variables in mind, even when optimizing your app workload in a very calculated manner, it would be extremely hard as a business to predict end-user behavior and produce a budget for these unknown variables.
It is extremely scary being charged on variables that you have no control over.
To charge workflow usage for development is extremely disheartening. I have an app where I literally built a side menu with 5 buttons (which is unfinished by the way) and that work alone has used 2,889 workload units.
I look forward to hearing more from Bubble and how they coach us to navigate this change. We have 18 months to figure it out or find alternative options.
