Forum Academy Marketplace Showcase Pricing Features

Database Trigger General Approach Question

I use DB triggers a lot. I love them, they are possibly my favorite Bubble feature.

I’ve learned there are (at least) two main ways to implement them:

  1. All DB triggers in one backend workflow, with the conditions set on the workflow steps. For example: this is more like a folder of workflows for any DB triggers related to Users. Each one of these steps has its own unique set of only when condition (e.g. when user before change is empty and user now is not empty to store new users in my Airtable backup DB).

  1. A parent-level workflow DB trigger with its own conditions. For example the one below, where all steps inside of this workflow trigger only run when the only when condition is met.

It seems to me that option 1 has a big benefit of making it easier to keep your app organized. Having all user related DB triggers in one location makes life easier (I have an equivalent one for 5-8 DB types).

What I’m wondering about is whether there is a performance and/or reliability tradeoff I’m making by implementing it this way. Does the fact that every change related to a user has to check through all of these steps come at some cost?

I’m primarily concerned with reliability over performance. Reliability because if a change doesn’t get handled properly, it could cause severe and un-debuggable consequences. Performance because these are on the backend and I’m nowhere near any of my capacity constraints as yet!

Thank you!

1 Like