Forum Documentation Showcase Pricing Learn more

Loading speed of "Do a search for" VS "List of Things, Things"


Hello everyone. I’m not exactly looking for help, as much as I would like to see what everyone’s experience is on database loading speed using two different methods, so that going forward I’m creating my databases in the most efficient way possible.

Since there is often more than one way to accomplish the same task on Bubble, I’m not sure which is really the “right” way to do it. When I started on the platform, I began building an app that grew and became a monster. The database has a few million entries spanning over 60 data types. The user’s dashboard necessitates that it is a one-page application, so there are many groups that show/hide based on custom states. Many of those have repeating groups to display various data types.

At the beginning, I didn’t really know of any other way to display the data in repeating groups other than using “Do a search for…” and adding the constraints, such as “Clients > Servicing Representative = Current User” to show only the list of clients that pertained to that particular “Representative”.

As time went on, I refined the database structure to save data types against other data types. Such as “Representatives” have a list of “Clients”, and so forth. My though with this was that having a smaller list of potential data to work with for each user would make repeating group load times much faster.

When the application contains thousands of “Clients” and you have to perform a search for only those “Clients” that match the particular constraints, it seems as though it would be much quicker to only display the few hundred “Clients” that belong to a particular user.

So, I set an example repeating group to display “Current User’s List of Clients” rather than “Do a Search for Clients > Representative = Current User”.

Now, here is where the questions comes in, and I apologize for the lengthy set up. What is you experience with loading times in your groups using these different methods. I actually found that the “Display list of Current User’s Thing” method was actually far slower than performing a search for a “Thing” with the necessary constraints. And this is a difference between less than a second to perform a search and display, vs 8-10 seconds of loading time to display a list of users “Thing” in the group. What is your experience, and is there something that I’m missing? Thank you for your input and feedback. Like all of you, I’m just trying to decide on the best way to serve information as quickly as possible to the user, when you have a big database.

This method is very fast
Repeating Group: Type = “Client”
Data Source = “Do a Search For Clients”
Constraint = “Representative = Current User”
Sort by: Last Name


This method is very slow
Repeating Group: Type = “Client”
Data Source = “Current User’s Clients”: Sorted by Last Name


It does seem a bit counter-intuitive, but my experience has also been to do method 1 listed above for faster results. From previous forum posts, I believe this is because the search runs server side (much faster) when using this method instead of client side.

What I do now currently in the app I’m making is run a couple default searches on page load, which get stored in states. Throughout the app, I’ll then manipulate these searches by using the :intersect with [new search] :unique elements. Seems to be working pretty fast for repeating groups, but I don’t have nearly as much data to handle as you do, and would be curious on if there’s a better approach to this.


Thanks @callen.hedglen. After doing some further testing, I did decide to revert back to the search method. I think I understand what you are getting at that it’s quicker because the search is happening on server side, vs the list being pulled client side. That makes more sense. I appreciate your feedback.


Sure thing! To add onto this, also make sure to do any sorting inside of the “Do a search for…”. If you add it on afterwards with :sort by, that will make it run on the client side and be much slower.


@jcindy81 How fast is the ‘Do a search for’ with millions of records?

Also about your one page app. Do you use display data in a repeating group workflows or are you using ‘Do a search with and you get constraints from staits or parent group with your hidden groups? Any speed difference with this?


Even with a huge database, the do a search for returns results immediately. At, least there is no noticeable wait time.

I have each repeating group set with “do a search for parent groups thing” and the appropriate constraints. Then all the various filter options for the data also use the same function, with “ignore empty constraints” checked to bypass any search filters that were left empty. The data still displays immediately even as the number of constraints grows. @callen.hedglen is also correct that any sort functions should be performed during the search portion, as sorting after the search adds a lot of time to displaying results.

I have not noticed any difference in using “search for a thing” as opposed to “search for parent groups thing”.

What I’m beginning to encounter now is my editor slowing down because of the amount of elements and groups that my one page app is using. I can work in it for about an hour before the editor crashes and needs to reload. I’m not sure if this is a bubble memory limitation, or my hardware. My machine has a core i3 and 24GB of RAM, so I don’t think it’s a memory issue on my end, but I don’t know enough about the bubble side to be sure. I also don’t keep extra tabs open when I’m in the editor, to keep browser memory open. Still, the editor is pretty sluggish to save after each change I make.



When the editor starts slowing down, just hit ctrl f5.
(Chrome). This will reset the cache and get your editor going
For the next hour.


Hi @jcindy81
Thanks for starting a great post!
Couple of quick thoughts…

  1. I’ve heard Firefox handles the memory better for large designs.
  2. I also have one huge page - about 40 instances of 40 different reusable elements each with about 60 elements on them. Takes a while to load, but still edits well.
  3. I’ve moved from lists of items to searches too. Much easier to handle and less to write when new things are created. What takes the time with searches is the amount of things returned rather than the amount to be searched through.

Good luck!
Antony. :slight_smile:


Very useful !! Thanks guys :wink: