An Update to Workload, Plus More Transparent Calculations

Thanks @emmanuel & @josh for listening and addressing many concerns. This is definitively a step in the right direction, nevertheless, I still have some doubts:

  1. Not being able to own my apps, just for peace of mind not to bring them anywhere;
  2. Unpredictability and uncertainty of costs;
  3. Fear and increased headaches while building & experimenting;
  4. Shadiness of system, unaligned interests of bubble w/ users

You definitively know better what the best business model is for your company, but I can’t hold myself from thinking that a simple, transparent and easy to grasp model is always the best, especially for a no-code platform. Further, YC pricing strategy seems pretty spot on and easy to implement, as per the picture here:

I wish the best to you and all the community and would much appreciate you address and explain your POV on these matters. I’m happy of being here and having found like-minded peers, hope Bubble will last and you will be ready to adapt to us, your users and biggest advocates.

2 Likes

What’s cool about Aaron is that I have no idea why he’s right but I’ll accept whatever he’s saying cause it sounds smart

@aaronsheldon just kidding :wink:

1 Like

A simpler solutions, opposed to a whole new table matching 1:1, may be to just add a “counter” field to the user. +1 and -1 as documents are added and removed, then you can just display the current users documents count.

2 Likes

Thank you @josh & @emmanuel for your much-awaited clarifications.

I understand that Bubble charges additional fees based on the server capacity we use for our application. However, I am concerned about the additional costs we will have to bear to optimize our application to minimize our use of server capacity.

To me, the chosen method is still not the right one. How can we predict the cost of something whose price we do not know in advance? Since the announcement of the WU with a sense of panic, I have been trying to improve and optimize my application. In just two days, I spent almost 200,000 WU just trying to optimize my application on some workflows and tests.

With the above examples, I realize that we need to seek to save money while spending money. In essence, it’s like the new economic model currently being applied by Bubble reflects this example: “Our company bought ink pens to save on printing costs. Now we spend more time looking for our notes than working!”

However, this can lead to high additional costs for application developers who have to optimize their code to minimize server capacity usage. Ultimately, this can lead to a paradoxical dilemma: to save money, developers must spend more money to optimize their application.

I am a strong supporter of Bubble and believe in the platform, but I am also aware that we must be careful with our budget. In order to reduce costs and maximize the efficiency of our application development, I suggest we explore other platform options that may be more affordable for us.

We could also consider using other services to host our application. These services may offer better resource elasticity and more predictable costs based on the actual usage of our application.

It may also be useful to conduct interviews and get real feedback from business models using Bubble. Some of the answers here on the forum are paradoxical and funny but fully reflect the reality that we are currently experiencing (as Bubble users).


2 Likes

A few thoughts:

IMO this approach is misjudged, super complicated and creates too much uncertainty.

The Pay As You Go principle isn’t the same as AWS / Google Cloud whose whole business model is based on providing incredibly low base rates.

  • Code can’t be exported. If you’re confident the hosting layer is market competitive, you should be able to let devs export their code. Then you de-risk these prices and give feature parity (non lockin) with other nocode platforms.

  • Not everyones most important criteria is speed of execution at any cost.

  • You still haven’t handled the scenario of what happens if a production app runs out of capped WU credits mid month?

  • It is ridiculously complicated and more than doubles the complexity of building on Bubble for real businesses. The learning curve to make sense of WU is much higher than the learning curve for building on Bubble - even if you’re a quant. I have no way of predicting what something might cost except in the vaguest of ways. The cost of optimising WU will be high in terms of WU!

  • Bubble is not architected for efficient compute costs or code patterns or client-side execution.

  • It creates a predictable tension for Bubble that to increase profits, increasing costs of WU is the lowest hanging fruit. You haven’t said - prices of WU will not increase above the US rate of inflation and will decrease in accordance with underlying index of compute costs.

16 Likes

These, very much please.

Since the beginning of this new pricing my pet peeve with it is that Bubble has decided to go ahead with the new pricing BEFORE making their own much needed optimizations and native user features for optimizing our own apps.

Optimization is the new meta Bubble has set so Bubble has to lead the way, faster and better than it’s users.

15 Likes

@josh @emmanuel

It is still too difficult for a non-tech person like myself.

And now I don’t trust that there is not a big catch in there because I don’t understand the complexity.

No code should be no worries.

Pricing should not be this hard.

I do not want to be checking a suite of graphs daily or weekly just to see if my blank check just got cashed

If I have to spend time sweating over my app as it scales, I can solve that worry, with only short term pain, by moving platforms.

(This time however, if things don’t change and I need to move on, I know to choose one of the several alternatives that gives me access to export code.)

26 Likes

@ccatalano that is another perfectly reasonable suggestion given the current state of Bubble. But isn’t it crazy that we even need to have this discussion? In 2023, shouldn’t a database be able to return a count of database records with almost no cost/resources?

I took some basic database admin courses in university almost 20 years ago and back then SQL could definitely do this sort of thing no problem. I know we are now into the era of “NoSQL” (or whatever the newest flavour of the month is today), but I strongly believe that Bubble should support all core database functions without the need for any ridiculous workarounds.

Can someone correct me if I’m wrong here, but with proper indexes set up, shouldn’t Bubble be able to return the count of even a huge table without doing much work? In other words, if I could do a “count of…” action in the Bubble object inspector instead of having to do a two step “search for…” + “:count” process ,wouldn’t it be an order of magnitude more efficient for both Bubble and my WU usage?

3 Likes

It’s not only crazy, but so disheartening. I absolutely LOVE Bubble and what I’ve been able to do with it. But I’m seriously considering switching to Dittofi since they’re clearly planning on moving forward with this. The learning curve seems steeper, but if they ever get crazy with their hosting then I can export my frontend and backend code and host it elsewhere. I can’t create a pricing model for my product around what Bubble is proposing.

2 Likes

While without seeing the impact of the WU re-weighting just yet, it remains to be seen how much it addresses cost issues with my particular app(s). But one thing that’s very helpful here is the Subscription Planner – boy, do I wish that had been available earlier.

Because what this points out to me, is that, putting aside WUs for a moment, is that the best case scenario for me is that pricing would be flat. The “Growth” plan, I take it, is the equivalent (feature-wise) to the current “Professional” plan?

One of my apps is on Professional with 2 extra capacity units and the current monthly billing (sans a plugin) for that is $133. And Growth seems to be priced exactly at that (well a dollar more - $134 paid monthly). Is that right, or is what I’m on right now more like “Starter”? (That is, for example, is the 10 custom branches feature a new benefit I’d get on Growth that I don’t have today?)

If my current features are more like “Starter” and let’s say I’m fine with that, if the WU re-weighting drops my currently reported WUs by half (again, there’s no telling until tomorrow if this is the case) then a Starter plan with 1 million WUs would cost me $141.50 (so, not a horrific increase and kind of hard to complain about).

But if I did that in Growth, I’d pay $233 – $100/month more than I currently pay (if paid monthly). So, is the premium version control and 10 branches and 14 days of server logs worth that to me?

I guess the other question I’m thinking about – since if I stay doing Bubble things – is that I like to be familiar with all features of the ecosystem. So, like, I would really like to understand the premium version control stuff, but may or may not really need that for my app, but might want access to that. Not sure I’m interested in paying $100/month for that, but it’s a consideration for me.

Is there an explainer for what is different about Growth and Starter vis-a-vis the soon-to-be legacy Professional plan?

All of these sorts of questions were completely obscured by (1) the complexity of the “tier” model and (2) the basic shock of “how can this be millions of WUs?”.

12 Likes

@ccatalano I should also have mentioned that in my app there isn’t necessarily a 1:1 ratio between documents and users. I have the concept of a Household, so multiple users can be creating documents that will be displayed to all users within a household. You suggestion could still work here, but it becomes more complex to make sure the counter stays in sync properly, and the extra work of searching/updating counters for different users will incur WU costs in the new Bubble pricing model so it isn’t even clear if this is more efficient than just sticking with my current code!

2 Likes

@josh @emmanuel when
When will I expect to see the new WU calculation update in my apps LOG?

While it is true that RDBMS will cache row counts on tables and sub-tree node counts on index branches, quickly getting those counts in Bubble will not work as expected because every application, EXCEPT those on “dedicated plans”, are all in the same database. From what I have heard they are using a substantial replicated Postgres instance. To get this to search quickly, or even return counts quickly, per application, would require fastidious attentiveness to the structuring of the indexes and keys. This gets even dicer when dealing with an underlying highly normalized table structure that can store the representations of Bubble’s versioned and dynamic “things”. Roughly I would expect the main value store in Bubble’s Postgres to look like:

CREATE TABLE BubbleNormalStore (
    ApplicationName TEXT,
    ThingName TEXT,
    FieldName TEXT,
    FieldValue TEXT,
    FieldType TEXT,
    ThingId TEXT,
    Created TIMESTAMP,
    Deleted TIMESTAMP
)

But that is all and educated guess.

4 Likes

Anybody else think it’s not too much to ask for a bubble representative to actually stick around to answer questions/ defend their pricing scheme?

17 Likes

Does a “make change to a thing” take up more WU as a fronted workflow or a backend workflow?

I put lots of stuff into backend to optimise my app & keep capacity down, but now I’m wondering if this will actually use up more WU.

Does anyone know the answer to this?

Thanks

Putting everything in the backend would make the capacity higher before and after this price change

I absolutely agree @Kent, to charge via WU, Bubble will need to take just about every possible combination of search result and expression into account.

I wonder how many WUs Bubble is using to calculate WUs? Maybe that’s why they’re so expensive.

4 Likes

To help, I’m humbly putting for consideration a new pricing system that combines what the community and shareholders have communicated to be valuable for them, being simple, predictable, auto scalable and tied directly with the resource consumption of each app:

Keep the capacity plans and charge more for them, if needed.
For auto scaling, charge per each minute where the app was exceeding 100% capacity, instead of killing workflows at that point.

Details:

  • Auto scaling is optional (app admin can turn it on/off ). If off, workflows would be killed when app surpasses 100% capacity.

  • Minutes over 100% capacity would have a price, minutes over 150% capacity a higher price, minutes over 200% capacity a higher price and so on.

  • App admin can setup alerts for when app has exceeded X amount of minutes over 100% capacity (or any % capacity, customizable alerts).

  • App admin can setup a monthly capacity overage cap in USD for minutes spent over 100% capacity.

Example:
I set my capacity overage cap to be $100 monthly. The price per minute over 100% capacity is $1 and the price per minute over 200% capacity is $2.

In the current month, my app have spent the following in capacity overages:

  • 90 minutes over 100% capacity (90 mins x $1 = $90)
  • 5 minutes over 200% capacity (5 mins x $2 = $10)
    Total spent in capacity overages until today = $100

Since I set my monthly overage cap to be $100, I’ve reached my cap. This causes auto scaling to be automatically turned off for my app. I would be able to turn it on again, only if I increase the $100 overage cap that is now fully consumed.

That’s it.

I believe Bubble could apply this pricing system leveraging their existing architecture, they already measure capacity and also minutes where the app surpassed 100% capacity.

Which pricing system do you think is better?

  • This pricing system
  • This pricing system with some changes (post your proposed changes below)
  • The WU pricing system
  • A completely different pricing system (post your proposed pricing system below)

0 voters

Just throwing some ideas to try to help you as you have helped many of us with Bubble. Thank you for listening.

@emmanuel @josh

4 Likes

Capacity pricing certainly created a beneficial economic incentive to self-throttle the workloads and distribute them uniformly over time. Get a lot done, but get it done slowly.

3 Likes

@Kent, I can’t vouch 100% on the database side for what Bubble does on the backend when asked for Search for Things :count. But I do know the Bubble plugin API very well and we know some things about how this all works in that scenario.

First, I do this in some of my test apps and it’s true that even with a very large database of some Thing (like more than 150,000 Things of a given type), Search for Things :count in a text element, for example, returns nearly immediately and doesn’t actually cause the values of the Search for Things part to be fetched.

But there’s some subtlety in how this works. The results of a Search are a single JavaScript object (which we call a List – I use capital L here to distinguish this object from a “list” (a Bubble array) in the generic sense). The List object has two methods on it: get() which allows us to “unpack” the List and turn it into a JavaScript array of whatever values it contains, and length(), which allows us to inspect how many items are in the List (this function returns what you know as the :count, in Bubble terms).

So, as you can see, we can actually know the length of a List without unpacking any of its items. It’s actually this process of unpacking the items with get() that, in the case of a list of Things, causes the Thing objects to be fetched from the database. And this is the “slow” part of fetching a List.

I take advantage of this in List Shifter, BTW. Well before any items are fetched, I publish the result of List.length() to a numeric exposed state that tells you the number of items in the List (it’s called Num Items or Number of Items or something like that). This is sort of invisible because I don’t trigger the initialized/updated event until everything has been done, but this Number of Items state gets published pretty much instantly and well before the items themselves are published to outputs like Original List and Shifted List.

So, if Search for Things :count works in the same way in a Bubble page as it does in a plugin, I guess one of two things could be going on with respect to WUs: Either the search operation itself (not the count part) essentially “gathers up” all the items, sending us info on how to eventually get() them and this gets counted as “that many things could be returned by the search” (even though in this case we never actually get them), and this might be a miscalculation on Bubble’s part.

But, on the other hand, Bubble doesn’t really “know” that we’re never going to get the contents of the List and, in the page, it might in fact just begin fetching them just in case. (If a List contains Things, those Things are also a type of JavaScript object that again has some methods on it to allow us to access the Thing’s fields.)

It’s probably only in the somewhat weird plugin case where we might ever exploit this, in the way I describe with List Shifter. When it unpacks the List, if the List is full of Things we actually don’t fetch any of the values in the fields – not even its unique ID – we just leave the Thing objects as they are and publish them to the Original and Shifted List states. So any further data fetching only happens when you eventually reference those fields somewhere else.

I can’t be sure about how all of this truly works with respect to the db. (Like, if a List is a List of numbers, do the numbers themselves come along as part of the List object? Or are the values only retrieved from the database when we actually execute .get() on the List? I have no way of knowing because the only way to “see” the constituent items in the List is to use .get(). I suppose I could inspect the Network activity but that wouldn’t 100% answer the question.

Anyway tl;dr: The count/length of a List can be determined without looking “inside” the List and, this action is pretty much instantaneous, and if you never unpack/get the List, is it incorrect to charge you for that?

Note that I have not inspected this sort of thing with respect to WUs yet, but I guess that’s another very nichey-niche thing that I need to understand now. No point in looking at this further until we see the new WU consumption in our apps tomorrow or whenever that gets released.

11 Likes