WU: Linked Fields vs Search For

cliffwoodjames · 2025-03-25T12:16:20.617Z

Hi all,

Just wanting to work out what the best option is for reducing workflow usage on my app. We’re using about 5k per day currently (which is just about okay) but expect that this might climb a little bit.

I’m hoping to figure out whether it’s more WU efficient to run “Do a search for” OR fetch a list from a linked type.

Here’s an example. Presently I use a hidden repeating group in a popup as a variable, the source for this is Do a search for callsigns.. then everywhere I need to on my page I’ll reference this RG’s list, rather than doing another search.

However, I’m wondering if it’d be better to instead do “Current user’s organisation’s callsigns” and link the callsigns to an organisation and thus fetch them.

Still figuring out all of this WU stuff, so would be great to hear insight on best practice for keeping the WUs down!

TLDR: Is it cheaper in WUs to fetch from a linked data type, or run a search?

Thanks

ademiguel · 2025-03-25T13:48:17.867Z

Let’s condense a proper answer

Do a search for expressions consume 0.3 WU just by performing the search. In addition, you spend 0.015 WU per returned item. And finally, you have to sum up the WU consumed due to the size of the retrieved records themselves (an orientative figure is 0.000003 WU per character).
Retrieving a list costs the same, but the 0.3 WU, because no search is performed, but a lookup.

The above is just about WU consumption, however, you have to consider more factors when deciding between a Do a search for expression and a list retrieval.

Hard limits. Lists can’t hold more than 10K items, while search results size isn’t capped.
Lists require maintenance. You’ll have to update lists to control what’s retrieved from them, plus additional maintenance to clear deleted records.
Lists skip Privacy Rules. This is a security problem in itself if not handled properly. Furthermore, Privacy Rules help limiting the amount of retrieved items, which limits WU usage too.
Searchs allow for server-side filtering, which frees client resources and returns less items, lowering WU usage.
For equal number of returned items, a search takes more time than retrieving a list

TLDR: you save 0.3 WU when using list retrieval vs a search, but you incur in several cons that might not make it worthy, especially when that 0.3 WU is small in comparison to the whole search spend.

A general rule of thumb is using list retrieval when the amount of items is not over 30.

Source:

Airdev on WU optimization best practices
Airdev on essential best practices
Bubble official docs on WU optimization

mitchbaylis · 2025-03-26T04:19:30.006Z

Personally I prefer doing search for - it’s just easier than maintaining a list on a thing for most use cases.

Bubble doesn’t have any cascading delete logic which makes maintaining lists rather painful. It’s just easier to delete the record and know that it’s not going to be a ghost data on some list.

Yes, you can add backend workflows to do the cascade deletes - I just prefer the simpler search method even though it uses slightly more WU.

I do however link single child datas on the parent since they are really joined at the hip.

ie
contact
contact_detail

Almost every relationship linking I create becomes more complicated than just a list on a data so nowadays I really think carefully about if it should just be it’s own datatype instead.

ie
list of companies a client works at is usually better as a data type
contact_company (contact works at a company but I’d also want to know their position, start and end date, status etc)

I also don’t need to return this list of contact_companies in 80% of the contact references so it doesn’t make sense to store the list on the contact - just better to search for it on the 1 time I need it.