Bubble Roadmap Update: Workload Management Tooling

Announcements New features
1

My name is Laura, and I’m a group product manager for our Growth team. Today, we wanted to give you a preview of upcoming releases to help you manage workload and some historical context for those of you who are new to Bubble.

We understand that the workload tools, visibility, and information we provide today isn’t enough. We want to let you know that we hear your concerns and the team is committed to giving you more tools you need to build with confidence on Bubble.

In the coming weeks, Bubble will be rolling out two new tools to help you manage unexpected workload spikes:

What’s coming soon

  1. Custom workload notifications: This will enable you to set custom notifications for workload unit (WU) consumption by specifying a WU threshold to trigger email alerts. When your app hits that threshold, we’ll send you an email so you can make any necessary changes, like pausing or updating workflows.

Modal (2)

  1. Infinite loop protection: This feature will allow you to set a limit, at the app level, to prevent infinitely looping recursive workflows. This will act as an additional backstop and supplement the constraints that you can add at the workflow level (i.e. “only when” conditions).

    • If you’re on a new workload-based pricing plan, you can consider using schedule API workflow on a list (SAWOL) instead of a recursive workflow to conduct bulk data operations. To learn more about the two methods, how they compare, and the ideal use cases, check out the Bubble manual article comparing recursive vs SAWOL.

Additional context on workload for those newer to Bubble

Our legacy pricing plans included a capacity usage metric rather than workload. Unfortunately, apps slowed down or didn’t work as well when they exceeded the capacity limit — they were “throttled” right when you most needed to keep up with increased demand from your end-users.

Last year, we replaced capacity with workload in our new pricing plans to help eliminate these concerns. Workload quantifies all of the resources needed to host, publish, and run your app. You can think of capacity as the speed limit, whereas workload is the fuel for your car: Instead of limiting how fast your app is going, workload keeps your app going as fast as it needs.

The future of workload management

In the coming months, we’re going to continue to invest in workload management and build more tools to support your efforts in estimating, predicting, and optimizing workload usage.

I’d love to hear about what’s most important to you as we continue to take on this work. Feel free to let me know in the comments. More to come!

— Laura

29 Likes
3

I think the forum already have a lot on WU stuff. Maybe you could share a list of what is on your roadmap to help reducing WU usage like for Schedule workflow on a list improvment. For example: To be able to select which field we want to be returned by a search query. Are you working on stuff to reduce WU usage when running DB CRUD operation? @josh talked about DB search improvment. Will this reduce WU for DB queries?.. Take time to read about WU topics on the forum and come back with more info. Thanks @laura.oppenheimer

19 Likes
4

Love the custom workload notifications! My clients get these emails all the time when I’m developing an app for them because usage is sporadic. It would be great if we could set separate notification thresholds for dev environment vs live environment.

6 Likes
5

Thanks for the suggestion @NexradJosh . When you say separate for dev and live - what’s the use case there? I’m curious what your mental model is for managing these allotments of WU and how that would want you to have different thresholds.

6

@laura.oppenheimer is there a visual of the actual roadmap you can share? And how what’s on the roadmap aligns to Bubble’s/Growth Team’s strategy? (if I’ve missed this, apologies in advance!)

I think the more you can communicate that “we’re doing this and this, but not this”, the better you can manage expectations and articulate some of the product tradeoffs you’re making.

5 Likes
7

Hey @rlowe012 - there isn’t a published roadmap right now but it’s something I can look into once our Q3 plans are locked down if that would be helpful. Historically our teams have been focused on two core areas:

2 Likes
8

This is very good and long overdue - it will only work if the notifications are sent on time though…

Future feature: returning specific fields from a search. EVERYONE wants this. I appreciate there’s complex editor/engine implications. An experimental feature that allows us to select the returned fields in the Do a search for fly out would be ideal. In the experimental stage, we don’t need issue checking (you can’t reference this field because your search doesn’t return it!) - the experienced users that will use this feature can already work out that if they reference a non-returned field it’ll be blank. Leave that problem for later, we just need the flexibility to return specific fields for now.

This is true, I think you and the team are already aware of what features actually matter to us.

There’s still one thing missing.

THERE IS STILL NO PUBLISHED LIST OF WU COSTINGS.

How did Bubble get it this far, I have no clue, but we STILL don’t know every action or interaction that can cause WU to be incurred. The slug setting is an example. The other day, I posted very frustrated because the manual said that we were charged WU for ‘search complexity’ and ‘database volume’ despite no values being provided! I was later told by Petter who wrote the manual that this is incorrect - and that’s not on Petter, someone from Bubble obviously told him that. If one of the most experienced people here can’t work out what costs WU and what doesn’t, how can the rest of us?!

Along this vein, breakdowns are essential in the logs. I know I PM’ed you about it but I’ll put it here for good measure. ‘30 WU used’ is not sufficient. We need ‘0.3 WU for search, X WU for API call, Y WU for amount of returned data’. Bubble knows these values (else how would they be calculated), so please, we need them in our logs!

I had a situation where one schedule API workflow (not on list) costed 3,000 WU, when I calculated it should be 20. Support didn’t really give me an answer (and how could they, they only know as much about WU as we do as they only have the same information we do) so I’m left annoyed because I can’t tell what me and my clients are being charged for, and Bubble incurs costs for support agents.

Common sense tools (particularly my later suggestions, I appreciate returning specific fields is a large project) are a win win for us and for Bubble. We understand stuff better, we both build trust, and you don’t have to staff a dozen support agents on doing the PhD level math to tell me how something was calculated!

20 Likes
9

As an addendum for historical context (for new users considering Bubble), here’s what I think other users would agree is a fair assessment.

How WU was announced

  • Prior to Spring 2022, Bubble charged based on capacity. As described in the original post on this thread, capacity is roughly how much stuff your app can handle at once. It was quite arbitrary but generally not something you needed to consider deeply.
  • In 2022, Bubble announced a new pricing system (for the second time, after the community overwhelmingly rejected the first pricing system that was not thought out). This new pricing system is Workload Units (WU). You are charged, roughly speaking, per WU your app uses. There is a reasonable grace period of 18 months, expiring in October of this year.
  • When they initially announced it, many people realised their app costs would be increasing by at least 10x. After a lot of uproar, Bubble cut the WU costs between 50-99%. That made the price moderately more tolerable, but broke down trust in the community, because it showed that Bubble thought it could get away with charging an obscene markup on their own measurement of computing power.
  • Objectively, the current Bubble WU cost markup is still obscene, though that’s the cost of using Bubble - it saves you development time and allows you to build faster. There’s nothing inherently wrong with charging a large markup, and the community was clear about that.

Limited tooling

  • The problem is that Bubble provided virtually no tooling aside from a couple of bar charts to analyse our WU usage in any meaningful way. We were promised continuous development of features to monitor, understand, and reduce our WU consumption. However, nothing really came. Currently, we have per action total WU logs, total app WU usage bar charts, and a pie chart you can drill down to view which workflows/data uses the most WU in your application, and that’s about it.
  • This was fine (not really, but whatever) - there would be 18 months before all existing plans would move to the new pricing. However, here we are 12 months later, and there haven’t been any meaningful updates aside from an email notification if your WU spikes.
  • Features we were promised that have not arrived include being able to limit the data that’s returned in searches (so we don’t need to send unnecessary data between the browser and the server). We were promised detailed learning resources that shows what costs WU, and how to calculate it. This does not exist as it should - the breakdown on the ‘what contributes to WU’ page is incomplete, and there are many things in Bubble that can cost WU that are not listed here (so, we’re being charged for things without being told what we’re paying for - did you know you get charged for scanning DB triggers?).
  • With that said, being on a WU plan has some benefits, the most important being that schedule API workflow on a list runs orders of magnitude faster, and your app won’t really timeout under high load (though, I’ve seen reports of Cloudflare rate limiting, which Bubble solves by pitching you the $3k/mo dedicated plan).

Bubble now

  • However, over the last 6 months, reliability of Bubble has nosedived, so the community here is left in a predicament.
  1. We are paying more, without knowing what we’re paying for. Nobody here really knows how it all works.
  2. We are paying more for less uptime and very low reliability.
  3. Community trust has been eroded, so new users and agencies alike are now deciding whether investing in building apps on Bubble is worth the risk. Many experienced users have moved to the likes of WeWeb, Xano, and Supabase.

Quite frankly, the rate of improvement on WU tooling has been embarrassingly slow for Bubble. I’m not flaming the team that’s dedicated to building this tooling - I bet they too wish they would be allocated more staff to build things quicker. But Bubble’s strategy with WU was to announce the pricing, and worry about the tooling later.

So, if you’re a new user coming to Bubble, you can make your own decision. I run a small agency. I’m still building new apps on Bubble but am emphasising to clients more often the platform risk of building on Bubble. I’m also seriously testing out alternatives. I think that Bubble will resolve its reliability issues, and I think that they will, at some point, make good WU tooling. However, I do not think that in 3 years, Bubble will be the leader in this space - many new tools are popping up that are leaner, meaner, and cleaner.

23 Likes
10

I think that would be really useful.

It feels like there is a lot of work going on in your area and other workstreams within Bubble, and I think Bubble miss a trick by not communicating the entirety of what is going on/planned to happen in roadmap form, beyond text-heavy messages about individual features (My brain isn’t big enough to track everything going on through written posts spread across the forum!).

Building on @Jici 's point, the uncertainty of not knowing what is coming next creates frustration, whereas at least with a product roadmap we can have a conversation about what is/isn’t on there and understand some of the prioritisation decisions being made (and give some feedback). You’re never gonna make all of us happy, all of the time, but if we understand the ‘why’ behind decisions it’s easier to accept and get behind them.

It would also be great to frame these as initiatives as user outcomes: giving us more tools isn’t an outcome. Something like ‘making workload management less complex’ would be, and is something you could put a metric on, measure the improvement over time, and use to help make prioritisation decisions (if we only have capacity to build one feature, will feature X or Y help most to move the needle on the metric?).

Sorry, this is slightly off-topic, but thanks for being open and engaging with us @laura.oppenheimer .

7 Likes
11

This is also very true, I’d love to know where Bubble’s spending its resources so we know what to expect. Feels like there’s no downside to Bubble for that, and it would lead to better communication with the community.

4 Likes
12

Yessssss this is great

4 Likes
13

Thank you for the feedback everyone. We appreciate the feedback and may reach out if we have more questions.

1 Like
14

Sorry - that may have been a little bit hidden in the bottom of my original post. I’m focusing on three user jobs here:

  • Estimate workload/cost (for building a new app or a new feature)
  • Project workload (how much will my app consume in different scenarios - as more users come? as I turn on a google ad words campaign? As a get a big new customers)
  • Optimize workload (how can I make this cost me less? Do I have the resources I need to do that? Is this fully optimized)

I’m not promising that I’ll be able to address each of these equally but here’s how I’m thinking (as PM) about the problem space in case that thinking is helpful.

6 Likes
15

I’m much much less concerned about WU costs than I am reliability! When the system is down the work stops.

16

As someone who’s managed to trigger (and pay) for 12 million WU’s the Custom notification will be fantastic. as long is its really timely.

I have multiple apps and getting the WU spike emails always sends me into dread. Especially if they come in overnight. delayed messaging is a big issue

Currently maxing out WU’s as an all or nothing affair - you either hard stop and lose the site or you don’t and potentially pay mega.

It would be great to see a staged set of user selectable options where you get alerts and potentially slow down processing as you get closer to your purchased limit. Eg alert at 50%, slow down and alert at 80%.

On a super positive note though the recent speed increases make up for consuming so many work units :smiley:

4 Likes
17

@laura.oppenheimer great news! I wonder if a low effort high value feature could also be setting a %/# value above current workload threshold?

Currently, there are:

  • allow overages
  • disable overages (app goes offline)
  • allow 200% (custom value) overages (suggested)

This could help with some risk tolerance - but you probably have a million competing priorities (and better ideas) :slight_smile: .

3 Likes
18

@laura.oppenheimer, thanks for the update. Can you please also address georgecolliers concerns/questions in this topic?

19

There should be a way to set a time frame for when we want a workload notification spike notification or to just set a limit for how many workload units used will shut the app down…because people Sleep some 8 of 24 hours (OMG that is 1/3 or 33.33% of the day) so, those notifications will do not much to help 33.33% of the time.

Yes, please do add back onto the roadmap the ability to specify what fields to return when performing a search.

Please add a feature so we are not charged for database trigger scans when there is no database trigger for the datatype modified. Absolutely ridiculous that we are charged for database trigger scans for data types that do not have any associated database change triggers.

Please make it so the URL path works the same way as URL parameters so that we can elect the ‘type of content’ and have Bubble automatically pull up the appropriate data entry so we can avoid having to do a search of the DB and it would work just like the SLUG function already does, which is we can use a slug or a unique ID…but this should work not just for the current pages content type or the first path list item, it should work for any path list item.

Give us breakdown of each cost of WUs, not just summaries. In logs if shows total WUs used, give a dropdown to see itemized details.

Give use WU predictive tools - ie: if I were to run this on 1,000 entries how many WUs would this cost or if I were to run this on 100 entries how many WUs would this cost…this will help us set pricing for our own software products

Do not charge for maintaining a backend workflow parameter as a list of things for each loop it is sent through. Treat those items as unique ids only until the parameter item is needed in the workflow and then charge for getting the information from server. At present we are charged for 1,000 entries in a workflow parameter on run #1, then 999 on run #2, then 998 on run #3 and so on. It should not be that way, especially since we are already charged for 1,000 entries when we schedule the backend workflow and send in the parameter list.

Get the engineering team to sit at a table together and write out the COMPLETE list of ALL things we are charged for…then have them go through that list and think rationally of ‘is this fair to charge for that’ on each item in the list…ANYTHING that is not fair to charge, stop charging for it. AND THEN, PUBLISH the list of EVERYTHING we are charged for.

9 Likes
20

To extend this, surely it wouldn’t be hard to have a ‘Get data type by unique ID’ feature/operator for dynamic expressions? Cheaper than a search? Do a search:first item gets tiring and is more costly! This already exists in the data API - let us have it in dynamic expressions.

That lets us do all sorts of useful things like convert a unique ID in format as text to a useable data type easily.

5 Likes