Question: List of Things vs. Search

I recently read “The Ultimate Guide to Bubble Performance” by Petter Amlie (great book) and have a question about how to structure my database with respect to List of Things vs. Search.

I’ve read that generally speaking, displaying data via Search (one-way link) is “lighter” but using Lists (two-way link) is fine if the List of Things contained within the data type is short. However, Search is preferable due to Privacy Rules. dynamic updating, etc.

Say I’m creating a project management app with the following data types:

Each User is a Parent to a list of Projects (100+)
Each Project is a Parent to a list of Categories (10-20)
Each Category is a Parent to a list of Vendors (10-20)

The app would display the Parent in an RG, then when an item is clicked, it will reveal a list of the Child data (ie: Click on a Project, it will display a list of Categories. Then when a Category is clicked, it will display a list of Vendors).

I currently have it set up so that each Child contains a link to it’s Parent and each Parent contains a List of Children (two-way referencing). However, I’m worried that this will cause performance / scaling issues as each data type will be quite “heavy” as each will contain a List of Things (and even more so since each Parent contains List of Children that each contains a List of Children, etc.).

I could instead “lighten” the data by employing a one-way reference (ie: each Child referencing a single Parent) and using Search to display the data. However, it would seem, for example, that I would then be searching through thousands of Vendors in order find the ones that reference the particular Category I am wanting to display.

Basically, I’m trying to determine the method that would provide the best performance / scaling. I’m a bit confused since the list to display is small relative to it’s parent, but large overall (ie: each User would have thousands of Vendors).

Thanks!

To put it simply, any search operations done completely in Bubble’s backend is super fast and you won’t have to worry about performance regardless of the number of records in your database.

That’s why having properly a good database structure to make full use of search constraints is very important for performance.

Performance problems stack when your search constraints return large lists to the client. Hence knowing when and why Bubble will return large lists is another factor in performance.

Just want to add that for data types that intend to relate to each other, i always have a field in the “child” that will link back to the “parent”. This helps to ensure i do not have to rely on advanced filters which work client side.

1 Like

Thank you so much, that’s a big help.