RG vs "Search for" (performance questions)

Hi guys! :raised_hand_with_fingers_splayed:

I was doing some tests and noticed that, if I load the data that I need (already filtered and manipulated from my database) previusly in a RG and point my “searches” and operations to this RG instead of use a bunch of “Search for” spreaded all over my page, my app runs smoother and I have almost no lag/load time.

So, my FIRST question is:
This make any sense? Someone else is doing things this way? What are the best practices when we talk about this comparison.

This said, here comes my SECOND question:
Is it possible to hold the loading process of a RG untill I want it to start? Like “don`t load the list untill I am sure that the user will need it”. Perhaps, start the loading process thru a workflow event of something… I tried to make them invisible but noticed that they still loads the data even when they are not “visible on page load”…

And, for last, my THIRD question:
Can I access all data in my RG’s list even if it is not seted as “full list”? Note that I am not trying to show the data, only to access it thru workflow and searches…

Thanks in advance!

Answering my SECOND question for those who have the same doubt…

Yes! I found this option in workflow’s actions. So, I start my RG with an empty “Data source” and fill it only when I need it thru the “Display list in repeating group” option in my workflow. Sweet.


Nice share! @rpetribu !

  1. Is a practice of what could be called clever “bubbling”. RGs are renamed to “data - things” or “var - things” … that way you find them easily when building expressions. Also, you place all your “variables” in a popup that you never open on every page. Popups are always loaded to the browser and you keep these nicely in one consistent place. Consider that this practice of setting or pre-setting data onto elements can also be used for single pieces of data (a “var - thing” group of type number, or type date, or type object of any kind in your dB. Going further you can also set a y/n expression in a “var - is this true?” group and use it to make logic building much much easier in other places like flows, conditions, etc etc) :grinning:

  2. Yeap … “display” is one. Another one is conditions in the RG where you set different data sources (… diff search expressions).

  3. My experience is yes


Nice discovery! I figured this out earlier today myself!!:muscle:


Thanks for the replies!

It is nice to discover that I am not alone :sweat_smile: and, most importante, going in the right way. I will keep doing these tests…

Correct me if I am wrong here…

But one thing that I think is important to put on the table here is that, as I read in the book “The Ultimate Guide to Bubble Performance” written by @petter (and indicated to me by @cmarchan), operations made in these lists (like group, filter and etc…) are processed in the user-side, and operations like “Search for” are processed in server-side. So it is clever to have it in mind when we think about performance, once manipulate a large amount of data in the user’s browser could be bad regarding user experience.

That’s why I am trying to load all the data that I need into my RG as filtered as possible, so I don’t overload my user…


The conventional wisdom after much time learning from knowledgeable folks in this forum (my understanding of it). And through my own experience building apps is to:

  • build light objects
  • minimize list fields (only when less than 100 entries), only use them purposefully
  • relate objects indirectly but both ways when necessary
  • preload searches
  • feed from preloaded searches
  • avoid inflow searches (… hence preloading them)
  • mnimize back and forths between client and server
  • use custom events extensively
  • schedule custom events when full data is needed within steps
  • use backend when processing is not needed immediately
  • recursively process key data

And more stuff covered mostly by @petter great guide, as well as, many other talented folks :grinning:


Hi! If it was a large list of texts (not things), do you think it will be harmful to performance as well?

Consider handle long lists of texts in one text field separated by a comma

I thought about that but what’s the max character limit for a single text entry?

@rpetribu, I suggest:

  • always use backend APIs when performing more than one DB action in a workflow that are parts of the same transaction
1 Like

If Bubble has followed PostgreSQL standards FFFF or 65,535 as per this link

1 Like