The Database Trigger Event spends Workload Units (WU) just like everything else that involves the Bubble server. This short article looks into how triggers affect workload and how you can optimize them to keep your workload as low as possible.
Before we dive into the details, let’s keep two points in mind throughout this article:
- Database trigger events are server-side workflows that trigger whenever a specific change happens in your database
- Workload is a metric that basically calculates the work that the Bubble server has to do to make your app run
Now let’s explore why those points are important.
Understanding how database trigger events are calculated for workload
In the Bubble manual, you’ll find a table that describes the different activity types that are calculated into the total workload, as well as the workload cost for that type. At the time of writing, that number equates to 0.05.
That doesn’t sound too bad right? Well, it isn’t – but it’s not the full story either.
Why? Well, database trigger events all happen server-side – that’s why they are so powerful. But this also means that every part of the complete workflow are calculated on the server, and as such they incur a workload cost. This is why the database trigger event is only a part of the story, and to set it up efficiently, we need to understand the full process.
Let’s have a look at each of these steps:
Step 1
For a database trigger event to fire, a change needs to be made in the database in the first place. Note that even if this step falls outside of the Total WU spend bracket, it still consumes WU. This simply illustrates that its WU consumption is not directly tied to the database trigger event (as in, this step spends WU regardless of the following steps).
Step 2
Bubble then needs to check whether there is a database trigger event associated with the database change that was just made.
Step 3
If yes, then any condition(s) placed on the events are checked. How much workload they consume depends on how they are structured. For example, the condition below would require Bubble to count the Friends field twice, consuming extra WU:
Step 4
Lastly, after verifying that the condition on the trigger returns a yes, Bubble proceeds to run all the actions in the workflow:
- Each action consumes WU depending on what it does
- Each action can have a condition, which also spends WU to check
Knowing all this, is the 0.05 value specified in the Workload activity type table inaccurate? Not really, but it requires an understanding of how the Workload Unit metric works in general.
Let’s use a metaphor, that’s always fun:
Imagine that the process you are running is an amusement park. The initial 0.05 covers the admission fee, but the rides, ice cream and cotton candy can still set you back a great deal more.
How to keep WU as low as possible with database trigger events
With the clever metaphor above in mind, how can we ensure that your database trigger events don’t run away with all your workload units?
The first point is one that I stress in many of my articles: don’t overanalyze and -engineer things. Workload units are there to be spent. Your job is to make an app that provide a useful, performant and secure for your users, and you won’t get there if you’re not ready to invest in it. On a weight scale, your user experience should weigh more than your WU budget.
That being said, let’s move on to the obvious follow-up point: it makes sense to not spend more WU than what’s needed for your app to run well. Let’s see how we can make database trigger workflows run at the lowest possible cost.
Checking the trigger spends WU, even if it never runs
Most database trigger events come with a condition, and it triggers if the condition returns a yes. Should the condition return a no, the actions inside never run and don’t consume WU. Still, recognizing the database trigger and checking the condition are server-side processes that do consume WU. If a database trigger event condition returns a no 80% of the time, you may want to restructure your app so as to avoid spending WU checking it repeatedly.
Don’t use database trigger events for very frequent changes
Database trigger events are highly useful for maintaining database integrity and making absolutely sure that a database change leads to a needed action. Still, it makes sense to be mindful of when to use it. Let’s look at an example to illustrate:
Let’s imagine that you have an app with a chat feature. Every chat message is saved in the database as a new record, and every time one is created you want to count them all for statistical purposes. You could set up a database trigger event for this, checking whether a new message is created and then counting all messages in the database. But should you?
From a WU perspective, you probably shouldn’t: the trigger and checking of its condition will unnecessarily spend WU for every single message that’s created. You could avoid this by counting the message in the same workflow that creates the message for example.
Avoid complex conditions
Database trigger events are limited to only two data sources: the thing before the change and the thing after the change. This ensures that you avoid placing very demanding expressions in the condition, such as performing a database search every time a database change happens.
Still, you should be careful how you construct your conditions. We can re-use the example from earlier in the article to illustrate:
In the condition above, we are forcing Bubble to count the number of records in the Friends (list of Users) field on the User twice: from a WU perspective this is a fairly demanding expression to run every time a change happens and you should consider simplifying it.
Avoid complex and numerous actions
As we explored earlier, the database trigger is only a small part of the story: the major WU consumption often comes from the actions that are triggered when it triggers.
Whatever you place in an action or its condition spends a given amount of WU, and as with the previous points, the more complex the operation, the higher the cost. Making changes to a list of things, performing database searches and placing a high number of actions inside the database trigger workflow can increase the WU consumption.
