The amount of WU you’ll spend in Dev mode, (which I still think is a joke) will likely be more than you’ll save over the month… rendering it a pointless exercise (WU optimisation)
Just the Bubble way.
So something that’s been apparent as I’m testing my app is that Tables are costing more then Repeating groups.
Tables are forced to load all the data, versus repeating groups which can be controlled.
This is terrible.
Yes, that’s because pagination isn’t included in tables so it’s what you’d expect. You have to set up pagination yourself using items from # / items until # to retrieve only the results you want to display.
The problem with this pricing plan is that its nearly impossible to know what your usage will be befkre launching. They need to add the wu into each worflow and each consition and each data source. When we build a workflow, it should be very clear how inefficient it is before going live.
Hey all, getting back to this. Here’s what I got from Petter:
Hey all,
I can see that backend db triggers are bit confusing, and happy to update the docs in a way that describes it in a more complete way.
The way to think about WU and backend DB triggers is that there are essentially three calculations going. Let’s call these “phases”:
Phase 1 (thing changes, start evaluation):
First, a user makes a change to any record that has one or more db triggers set as its data type. All database trigger events watching that data type are alerted (evaluation).
Phase 2 (check the condition on the trigger):
Then, Bubble checks the condition on the relevant trigger event(s). The cost of checking that condition is independent of the initial evaluation, and performs the needed lookups etc to verify whether the workflow should run.
Phase 3:
If phase 2 returns a yes, then all actions (and dynamic expressions in those actions) are executed and WU for that is calculated – again independently of anything that happened before.
It’s important to see each server interaction in isolation; for example, while the db trigger (phase 1) leads to the checking of the condition (phase 2), these are two independent interactions (an event and a dynamic expression) that are each calculated. Continuing that logic, anything in subsequent actions/dynamic expressions within the workflow are also calculated independently.
Does that mean this no longer is true?
The support agent quote above seems to contradict what Petter wrote
This needs further clarification on which quote is correct. I have not performed a test to verify, but last time I tested this, the support agents quote was accurate.
Just an FYI for anybody following the thread or who comes across it…I had to follow up with Bubble support on this to get the needed clarification on which quote was correct.
Below is what support replied
I’ve reviewed this conflicting information around database trigger scan charges, and confirmed from our engineers that the information our Support Team gave previously is accurate. That is, a scan for database triggers occurs whenever a data type has changes applied to it.
From the sounds of it, we are charged for a database trigger scan even if you do not have a backend database trigger change for a data type that is changed. I actually had to follow up again with the below clarifying question, as the conflicting information is concerning.
So this means that if I have a data type called “Product” and I have not setup any database trigger change backend workflows in the app at all (literally I have zero database trigger changes in the app), that every time a data entry of the Product data type is changed, I will incur the WU costs of running a database trigger scan, even though I have zero database trigger change backend workflows in the app?
I tested and wasn’t able to find this.
When clicking a button, a simple make changes to thing (unconstrained Do a search for:first item on a very light data type so negligible data returned cost) costed 1.42 with no backend triggers.
When I added a backend trigger with no conditions that has no actions, the total WU usage was still 1.42 and I was not charged for the empty backend trigger.
When I created another backend trigger with no conditions and no actions, WU usage was still 1.42.
So, backend triggers with no conditions appear to not trigger the 0.05 WU scan fee.
When I created a third backend trigger, this time with 'Thing now’s unique ID is not Thing before change’s unique ID, it was still 0.42 (so I guess retrieving Thing now and Thing before change is free).
I certainly wasn’t charged for a condition evaluation even though one certainly was evaluated 
Maybe file a bug report 
Actually this statement just sounds like engineering is confirming that a scan is made for every data type that has changes applied. Doesn’t confirm how and when WU charges are made.
Really appreciate the updates!
Yes. That’s why I needed the follow up question, as the previous versions of it may not have been understood clearly.
So this is the final answer from support
Our engineers confirmed that this only applies if a trigger exists on the data type in question.
Glad there is finally clarity.