How does bubble's DB actually function with list fields

I am just looking for some insight into how bubble deal with List fields, so I can understand how it might impact on speed.

If I have a list field in my DB, and my form is based on that table. Does bubble load the data in and run queries irrespective of whether I have that displayed on the form, or are the queries only done when I actually display that data.

Additionally, how does that work with self joins.

I have seen a couple of very slow solutions, one with 19 list fields in the user table, and I am suspicious that the time to load of the page is being affected by this fact, even though the solution has very little data in it?

It would be useful to have some insight into what Bubbles engine is doing in the background, so we can structure the DB to improve speed.


Hello @d.pearce


Thanks All,

I am seeing a lot of solutions where I think “List Fields” are misused.

i.e in the convention CRM you have:

Companies and Orders.

So I would always use a foreign key in the orders table and link idcompanies to fk_idcompanies.
I see people in Bubble using a list field in the Companies table.

List of Orders

I cant help think that that is very wrong as the List field will be an object that is not indexed.

Also if you have s subsidiary table used by multiple companies, then I would expect to use a:
companies_to_orders table with simply an fk_idcompanies and and a fk_idorders field.

I assume the are indexed and traditional relationships when i define them a fields from the other tables.

I can see for a post which might have 20 likes, how the list field could work well, as all I want to do is count the users who like, but I fear it is dangerous relating in this way when I might want data or to sort the data in a repeating group at some later date, as this is an object??? (is it!) relating to the secondary table.

I think the answer that says dont use list fields if you have more than 100 things in it, appears to confirm my suspicions.