List or Searches - Which is faster in fetching data in Bubble?

If you have a list of 50-100 items, you can use repeating groups to display them in Bubble without problems. But once you have several hundred entries on the screen, you may start experiencing slowdowns.

Google spreadsheets can handle vast amounts of data, but Bubble would struggle. Bubble can't display data as well as a Google spreadsheet.

That brings us to another question related to app performance - which is faster fetching data in Bubble? Is it quicker to fetch data from lists or searches?

What is the difference between Lists and Searches?

Lists and Searches have pros and cons, but both are useful in different instances. The use cases depend on a few factors; no one approach will work in all scenarios.

A search is performed on a data type with constraints to filter out specific results. This approach ensures that we only fetch and download the specific records.

Lists, however, are saved as a field in a data type. They don't have their own separate data type. An example of a list is a list of texts stored in a data type. This list can be used to store notes, updates etc., and it will be a single field inside a single record.

Filtering data using Lists and Searches

While most database searches are performed server-side, lists depend on client-side filtering. That means the user's hardware dictates the performance of list filtering.

This can be a severe handicap for businesses that need to cater to people with low-end devices or poor internet connectivity.

Complex searches using Lists and Searches

Searching for records in the database with specific criteria like Team name or Status=true is fast.

It is not always easy to get more advanced searches without merging and intersecting multiple searches into one list. This can cause the server to do various searches and move processing to the client-side, slowing down searches with many records.

As lists also use client-side filtering, this can negate the speed and scalability advantage that Searches have over Lists.

How to decide between Lists and Searches?

There is a general rule of thumb which we can use.

A list will be faster if you know that the List will not have more than 20-30 items. Let's say you want to store a list of User Roles that an employee is granted. There is a definitive upper ceiling in this case, and the list will be small. It makes sense to store it as a list rather than storing it as a different record in a data type.

If, on the other hand, you want to store the products that a user has liked, a list will be slower. As there is no definite upper ceiling and the user can potentially like hundreds or thousands of items, storing it in a different data type makes sense.

You can create a new data type, Liked Products, and a link to the User and Product. And when you need to display, you can Search the Liked Products table.

A list is helpful when the number of items in the list won't be large. According to Bubble's co-founder, Josh

If your list is short – you know you'll never have more than 20 - 30 invoices per company, for instance – then yes, using a list will load a little faster. However, ... the list will start slowing things down once the total number of invoices goes beyond the number you actually want to display at any one time.

Lists are great for small data sets, but please don't use them when you don't need to. To create a feature similar to wishlists, likes, retweets, etc., where the number of items can be thousands, use a different data type to store the information.

If you need some help with your Bubble app or a team of Bubble developers to build a Bubble app for you, reach out to me at himanshu@nocodeassistant.com. You can also follow me on Twitter.