Transparency in WU Charges: Let’s Unite for More Clarity!

Need help
1

Hello, Bubble community!

Many users have reported issues with the lack of transparency in Bubble’s Work Units (WUs) billing system. Complaints include unexpected charges, bugs, and, in some cases, charges that appear unwarranted, which is creating insecurity among developers.

There is a growing concern that users may be paying higher bills due to unknown bugs in WU calculations and undocumented WU consumption. This lack of clarity makes it difficult to control costs and optimize applications, as developers are left uncertain about what’s actually being charged.

One widely discussed example is the use of hidden Repeating Groups (RGs) to save resources. Some users suggest loading all data in a hidden RG and then applying filters in a second visible RG to utilize the already loaded data, believing that this would prevent new queries and reduce WU consumption. However, others say this approach doesn’t work and that Bubble continues to perform new database queries, resulting in additional charges. It’s essential for support to clarify if this practice really helps to reduce costs or if it’s a community myth with no effect on WU consumption.

Here are a few ways we can strengthen this movement:

  1. Like to Show Support: If you share these concerns, please like this post! This will help highlight the topic as a priority for the community.

  2. Share Your Experiences: I encourage everyone to share how the current WUs system impacts your work, particularly in terms of performance and costs. It would also be very helpful if you could share experiences where support couldn’t fully address questions about excessive WU consumption—especially in cases that seem like bugs, such as infinite loops or WU charges for processes that don’t make sense or aren’t clearly described in the documentation. Detailed stories can help build a clearer, more impactful narrative for support.

  3. Request for a Webinar Focused on WU Consumption: It would be incredibly helpful if Bubble could organize a webinar specifically to clarify how to reduce WU consumption and address major questions. In this webinar, support could demonstrate practical tests on WU consumption and how to optimize it, showing “before and after” results of optimization. Ideally, they could focus on key cases where optimization really makes a difference, clearly distinguishing fact from myth and detailing WU charges that aren’t explained in the documentation.

With greater transparency, everyone will be able to develop their applications with more confidence and efficiency. If you also believe in the importance of understanding and controlling costs on Bubble, join us in this initiative and leave your comment!

Thank you for your support! Together, we can make a difference!

5 Likes
2

I am interested. How do you plan to go about it?

I have been having this hidden RG confusion as well, and have been meaning to dig it up to understand what it is.

There are many other such questions. I had put those once in this thread: Submit your WORKLOAD questions! - #2 by mghatiya

3

@mghatiya Thanks for your interest! I’ve updated the main post with more details on some ideas I think we could pursue together to get Bubble support’s attention.

The plan is to gather community support by encouraging everyone to share their experiences with WU consumption, especially in cases that seem like bugs or unexpected charges. Additionally, I suggested that Bubble support could hold a specific webinar to demonstrate practical tests on WU optimization and clarify recurring questions. This webinar could be a great opportunity to clarify what’s documented and what’s not, and to show “before and after” optimizations in cases where it really impacts WU consumption.

Feel free to add any questions or concerns about WU usage here as well, especially the ones you mentioned back in 2023. That would definitely help reinforce our request to support!

4

Hi @fede.bubble ,

I’d like to invite you to join the discussion here. Since you’re part of the community team, your perspective would be very valuable, and I believe your participation would help enrich the conversation.

If you could share the points raised here with the rest of the Bubble team, that would be great! I’m sure that many of our concerns, such as transparency in WU charges and potential bugs, could provide useful insights for the team to better understand the community’s needs.

Thank you for considering the invitation, and I hope we can count on your support to move this message forward!

5

I sent a link to the thread to the team so they are aware.
Thanks for sharing!

2 Likes
6

using hidden repeating groups is the best way to reduce workflow usage about half the time… and in short it depends

essentially what you need to reduce is “data received and processed”

so if you have a repeating group that then does a search to count records that are linked to each item, or a search to list those items you end up doing a lot of data calls

simple fix: put a master search as a hidden repeating group outside the repeating group you want to show data within. now you return a few hundred items and then FILTER them (client side) for each repeating group row.

much more efficent in most cases

where it falls down if if you do searches within the filters - because now you’re still doing database calls for those searches even though the filter is on the clients side.

another fallback is that if you do a master search and return tens of thousands of records then it takes a lot of processing client side to filter them… so a long time to load and still a high workload usage.

simple fix there is to add a predefined filter to the search that the user can adjust - ie a date filter to only return records in the last 30 days etc, or status/type filters that are applied by default but can be toggled by the user.

however whilst we’re on user toggled filters - it’s important to mention that in most cases these should be applied client side AFTER the database call and not in the database call itself. because if you put them in the database call then each time the user changes a filter it recalls the database (slow and uses workload)

in short - the bubble workload usage is an absolute spaghetti tangle of logic that devs have to discover and figure out for themselves. but if you understand the basic principle of search for (calls server) and filter (works client side with no workload usage) then you can hack around and reduce workload usage considerably.

I must add that the workload report is pretty useless. and the built in debugging/logger is absolutely useless. for anything that I debug I add my own debugger steps into the workflows by using a basic data type that I simply write useful information into - ie I’ll write the result of all the calculation steps so I can go through each and see what is wrong. it’s much clearer and easier than using the built in debugger since I can just add those steps to the faulty workflow and check the database for the “reports”.

another point about database searches - if you just need to get a count of something then it’s actually more performant to call the server for that count than it is to reference a repeating group containing the records. this is especially true if you are hiding the repeating groups and only showing them on a toggle. the data is only loaded when it is displayed or used in logic so if you count the records in a hidden repeating group that isn’t displayed yet but shows 20 fields to the user then all that data has to be loaded from the server for all the hidden repeating groups - just to get the count of records. so it’s more performant to do a search and return just the number instead… it’s these little tweaks that can really reduce workload usage.

also, if you are doing those sort of aggregates often then you’re much better to store those numbers on things rather than searching for them. ie you have an invoice number that counts up for each created invoice.

you could search for the highest number each time an invoice is created but that’s not performant.
instead you’d be better off holding that number on a data and just adding 1 to that number each time an invoice is created and then just search that 1 record to get the current count (I usually create a “system” or “admin” data for this purpose)

none of this is well documented anywhere but hopefully whoever comes to this thread will at least find some help with these points. I build bubble apps full time and have done a lot of workload tests to optimize them.

something that is not clear to me, but I think happens, is that filters that run in backend workflows - I think they are workload usage since that there isn’t a “client side” to run them. I’m not 100% but I can’t see how they could be client side given that there is no client since backend workflow is server side.

in backend workflows it’s also more performant to do a search of a list once and then pass those records through to other steps/workflows in the chain.

as a basic rule of thumb - you want to reduce how many searches you do in your logic.
and a second rule - reduce the use of advanced filters and nested searches/filters where possible.

4 Likes
7

I think it is just hard for Bubble to change anything about this.

Bubble has real time as default which is handy and a beautiful thing in most if not all cases but not when Bubble starts charging for WU. Because now we have to work and think hard how and where we are going to stop the real time feature.

Seems logical when real time is an option that we can switch it on or off when data handling is involved. But that is probably hard to change now in the Bubble code.

And to be honest, Bubble is trying to make a profit so why would they change it, as at this moment any new Bubbler, or not yet expert Bubblers, are automatically paying more than perhaps is needed. After all, not handling data updates and search for will cost WU every single time a user opens a page.

1 Like
8

@mitchbaylis , thank you so much for the valuable tips! Your suggestions on optimizing WU usage are incredibly helpful, especially around the use of Repeating Groups and client-side filters. Unfortunately, guidance like this isn’t well-documented by Bubble, and the lack of clarity in the workload report and debugger makes the process even more challenging for all of us.

It would be fantastic if Bubble could organize a YouTube live session or create video tutorials with practical optimization examples, improving transparency and support on these critical topics. This would benefit the community and strengthen Bubble’s commitment to user satisfaction.

9

@sem , the real-time update feature is one of Bubble’s most notable functions, but it can be a double-edged sword when WU costs come into play. I agree that it would be ideal if we had the option to toggle real-time updates on or off for data processing—this would help us optimize WU usage according to each application’s needs.

I understand that making this change in Bubble’s code might be complex, but if it’s not possible to implement such control, I believe the least Bubble could do is improve the documentation by creating clearer tutorials, informative live sessions, and taking this topic more seriously. This has become an essential priority for many of us. Both startups and non-profit projects that don’t monetize their applications, as well as any platform user, could end up paying more than necessary due to limited knowledge and the current lack of transparency around WU charges. In my view, this situation is unfair and negatively affects both users and Bubble’s reputation.

Let’s hope Bubble (@emmanuel , @josh ) truly considers this feedback and moves in this direction, as adjustments like these would benefit the entire community and, in the long run, add even more value to the platform.

Thank you for sharing your perspective!

1 Like
10

This is not quite right. Generally speaking, using :filtered on a hidden RG does searches on the server rather than the client. You just highlighted a general misconception about how Bubble processes data expressions.

:filtered runs server-side where possible. You can often force it to run client side using an advanced filter. You can read more details about this here.

This is also generally not the case - search expressions are not re-used in backend workflows.

4 Likes
11

One thing to be aware of…if you had a data field that was populated in some of your data entries, and then you delete that field, the search will still return the deleted fields values.

Screen Shot 2024-11-06 at 9.41.01 PM
Screen Shot 2024-11-06 at 9.41.01 PM895×511 77.8 KB

2 Likes
12

Wow, there’s a lot to learn in this WU business.

Bubble has made us busy in this busy activity which doesn’t really help us make better apps and we have to struggle to find all these to save money from this overcharging pricing scheme and model.

1 Like
13

In some ways it does, like optimizing for performance

more or less struggle to figure out the inefficiencies Bubble has that Bubble should have tested on over the past 18+ months

14

This discussion highlights an urgent issue for the community: the need for more clarity and education around optimizing Work Units (WUs). Many of us are working hard to optimize our apps, but without comprehensive and transparent guidance from Bubble, it’s difficult to know if we’re truly on the right track.

It seems that Bubble may be, in some ways, ignoring or downplaying this important issue. The number of forum threads showing confusion and frustration with costs and lack of transparency makes it clear that this is not an isolated problem, but a collective need. By prioritizing other improvements instead of addressing this lack of documentation and support, it seems that Bubble might not recognize the long-term impact this could have on community trust.

What we’re asking from the Bubble team is:

  1. More comprehensive and in-depth documentation on advanced WU optimizations, going beyond the basics;
  2. Regular video tutorials and webinars exclusively on WU optimizations, hosted by Bubble experts, to answer community questions and share best practices;
  3. More transparent and detailed documentation, covering everything that consumes WUs, as there are reports on the forum of users being charged for WU consumption not documented. This makes it almost impossible to accurately plan operational costs.

If WU charges are fair, the least we ask for is the necessary educational and technical support so that we can optimize and plan with confidence. This is not just my request, but one shared by the entire community that relies on Bubble. We hope that Bubble takes this matter seriously and demonstrates a commitment to transparency and the success of its users.

1 Like
15

I’m shocked and extremely concerned that when a field is deleted, the associated data remains accessible in searches, potentially exposing information that should be protected. Imagine a company that stores sensitive client information – like Social Security numbers, addresses, or even financial data. If a field with this kind of information is deleted but the data remains accessible, this creates a critical risk of sensitive data leaks that could seriously damage the company’s trust and reputation.

I found a post on the forum discussing this: Data Deleted or Not? Security Concern, but it seems the issue hasn’t been resolved. I would like to know from @fede.bubble or the support team what is being done to address this serious security concern. Many users are unaware of this risk – I wasn’t aware myself until now.

1 Like
16

They posted some info in the thread:

1 Like
17

The field still exists until you do a “optimize application” and remove the deleted data fields and option sets and styles etc. Essentially the fields are just soft deleted so the user can bring them back if they change their mind. So the actual database isn’t changed until the optimization is run to hard delete them and the data in them.

You can greatly reduce data sent to front end by leveraging the privacy rules as well since only the data that a user is allowed to see will ever be sent to the client side.

** hold up. just checked the devtools for this as I had assumed that my understanding of this and the documentation for it was correct - which it is not. all deleted fields still exist and and still sent to the client side?! I’m really struggling to believe that this is actually what is happening but it is. Every single field that I have deleted and also “hard deleted” with the optimize app function is still returned in the json when I fetch a data thing. That’s absolutely unimaginable and a massive security flaw because I can’t even restrict those fields with privacy settings now since they no longer exist… lol

18

That is different from my understanding of the official bubble documentation here

In that documentation it states that searches are down server side and filters are done client side. It gives the example of “filters added to an already completed request” are handled client side.

ie - perform a search hold the results of that search somewhere on the page - in a repeating group. Then filter those results - the documentation gives the example of “using an expression like Repeating Group User’s List of Users:filtered”

and states that "this filtering will be done instantly on the client side, with no WU cost. "

my understanding from that is that there are 2 ways to do a filtered search.

  1. add the constraints into the search request itself (server side)
  2. apply the constraints after the initial search has resulted on the page using :filter (client side)

ie
search for music where the search results contain type = rock
vs
search for music > return results > filtered to type = rock

both show 10 records to the user
but option 1s result is 10 records
whereas option 2s result is 20 records (because no constraints applied in search), then filtered to 10 on the client side using :filter on the returned data

I’ve spoken to several bubble “support” and they’ve all said the same thing. Filters happen client side - and I believed them and setup all my searches that way without considering that they would be wrong and the official documentation they pointed me to would also be wrong.

But when you replied I thought I better actually test it and check the devtools to verify who was right (I assumed I would be - which I am not).

I performed a simple test on the page.
1 dropdown for the user to toggle an option set filter (option set is saved client side so no server request should happen here)
1 repeating group to do the unfiltered search
1 repeating group to display the unfiltered searches results and then filter then on the client side using the drop down. - this is exactly how they say in their documentation - “Repeating Group’s List of Data:filtered”

The result - a call to bubble server each time the dropdown changed!
Frustrated I decided to check if I could cache the list on the page somehow - which seems only possible by using a state.

Then I used the states list and filtered it by the dropdown and no additional calls to bubble servers.

So lesson learned. Don’t believe anything in the official bubble documentation or even the support team and do the hard yards to figure everything out yourself or through the forum.

19

Advanced filters will almost always force client side, but :filtered runs server side where possible.

@petter might want to check this paragraph:

However, filters added to an already-completed request will, in most cases, be performed on the client. For example, if you have a repeating group of users and want to further filter the list by a field like age (using an expression like Repeating Group User’s List of Users:filtered), this filtering will be done instantly on the client side, with no WU cost.

It is more common that filters on already downloaded data perform additional searches than it is for them to handle it all client side.

20

just retested the deleted fields still being returned in the json sent to the client and it happens.

I setup a new app
added some fields - labeled one “deleted” for easy reference

deleted it
then optimized the app to hard delete it

checked the data on the page at all 3 stages
field exists
field soft deleted
field hard deleted

field always returned to page even after optimization runs
now field cannot be set in privacy since it is hard deleted - lol