The nono's of a Bubble datamodel

Hi everybody,

What are the most common pitfalls you see concerning the datamodels used by other Bubble users? In multiple threads I see the experienced Bubble users comment a lot of databases they come across will not scale. So why not? What are the most obvious nono’s?
Asking as an oblivious non-developer.

I can tell you as someone who is working on a small app - bubble is not meant for heavy database driven apps. There is no way it will sustain.

Try changing data (things) as less as possible, and work on optimizing workflows.

I try very hard to only be positive on the forum, and not get into arguments, but that is complete nonsense.


Nono #1 - Using text fields to link tables

So if you have a “Book” which has an Author, don’t make that field a text, and then search for “JK Rowling” in another table to find their details.

Give the Author field on Book a type of Author.

Nono #2 - Using Unique Id to link tables

Every thing in Bubble has a UniqueId.

But don’t store the UniqueID of your Author on the Book table as an alternative to #1

If you find yourself using the UniqueID to search for things … have a really good look for another way.

Nono #3 - Using Lists of Texts

This is rarely the right thing to do, you are usually better off listing a Recipe’s Ingredients as a separate table, and link to it, rather than “Flour, Eggs, Sugar”.

If this is a very trivial list, with no requirement to process the items further, then fine, but think before you do.

Nono #4 - Overusing Relational Database thinking

Bubble is not a relational database. Many apps do not use relational databases now. Getting obsessed with 3rd Normal Forms is waaaaay too much overthink.


@NigelG I’d genuinely like to know why its a complete nonsense.

I absolutely love bubble, but i don’t think it will handle large databases very efficiently.

Nigel, could you explain this point a bit more?

Define “large” “handle” and “efficiently”.

I am not shy in being critical of bubble, and some aspects (like the data tab) are not great. But I have not seen problem with large volumes across the platform.

If you can be specific, then I may well agree. But just being vague about data handling isn’t helpful.


Sure, I’ll be specific:

  • “Do a search for…” is almost always slow for me even when searching 100 entries. Sometimes there is a workaround to avoiding using it though.
  • Writing data is slower than other web frameworks (even though bubble is not really a framework) its understandable, but if i had to modify data on every page load for example, i can’t imagine using bubble for it.

Also, there is cost, correct me if i’m wrong but I’ve recently found out that the personal plan can manage about 100 workflows per minute and the professional plan about double than that (With mixed server and client side workflows).

1 Like

Surely that depends on the search. If you are simply searching 100 entries and it is taking a long time then there is something seriously wrong. It could be the query, or some other technical issue, but it should not be that slow.

1 Like

Yes. Bubble is based on Postgres, which in itself of not really relational.

But then we don’t know how Bubble stores our data anyway, so getting too deep into relational thinking is not all that productive.

It is well worth thinking about not repeating yourself and the other broad concepts of relational database design, but I don’t think it should be an obsession.


Thank you, Nigel!

Given your experience with Bubble, may I ask if, in terms of performance (e.g. search for), if makes positive sense to have many different types [tables] instead of just one?

In my app I organised everything using a single type [table].

Instead of having multiple types [tables] I assign codes to rows. For example, I could have a table called counties and a table called cities, then have a parent field in cities referencing a country.

Instead I have one table called elements and for countries I have elements with code 1 and for cities I have elements with code 2 (each row has parent element field…).

Would my app perform better if I have different tables rather than just one (in Bubble environment specifically)?

Cool, yes this is very educational @NigelG . Both Manual as the reference guidebook ( including searching on the forum) left me with the question what actually are the right practices for a database setup here. This input from the Bubble experts prevents a lot of slow performance :slight_smile:

I have an app that searches across 100,000 items, based on an input and a menu.
It rarely takes a few seconds. It’s pretty much instant for the amount of items

1 Like

What you’re describing is the exact opposite of the Bubble model. The metaphor in Bubble is make virtual representations of things.

(Does your system need user roles? Make a Role thing. Does it need Calendars? Make a Calendar thing. Do your users specify a favorite type of meat? Make a Meat thing and only admins can create new meats so there’s no funny business, right?)

Whenever you DON’T do this, you’re going to hate yourself at some point down the line.

User roles are not a list of texts, they are objects with parameters. Characteristics of your users should not be a bunch of yes/no fields. Etc.

Doing things the way you’re describing is going to kill performance. Don’t even think about it.

1 Like

Would it be possible to launch a social media app through Bubble?

This is a bit of an off topic question, but yes, it’s possible. For more information, I suggest starting your own thread or searching for some of the other threads where this question has been asked.


I agree. I am working on a SaaS Used Car Dealership Management system and it is a complex relationship data driven app. No problems so far…



Nono #2 - Using Unique Id to link tables

Every thing in Bubble has a UniqueId.

But don’t store the UniqueID of your Author on the Book table as an alternative to #1

If you find yourself using the UniqueID to search for things … have a really good look for another way.

I’ve been working on a pretty large app for over a year now and I have found myself having to do this with only one “major” feature. It’s basically doing a "when notification id(unique id) = current pages unique id

Essentially I’m using it for a notification system that has to go back and forth between two users, but it has to display dynamic results on each end that are different each time, so after much consideration, this was the best way I could figure out how to do it.

Now, I’ve obviously only used it on a smaller scale while testing my app myself, but so far it runs flawlessly and very quickly. I hope this continues to be the case because I’d hate for things to run slowly. Reading other comments here, I think it should be fine.

The one times I’ve noticed the “search for” function running slowly is when I “do a search (datatype) merged with do a search for (datatype) merged with do a search for (datatype)”. That type of search where you are searching multiple data types is pretty slow.


I believe going through 100,000 records is not a difficult job for AWS at all. Or am I wrong?

Two cases:

Case No. 1. 2 tables of 10,000 rows (Parents and Children)

I want to search for Children of a Particulate Parent: I search for a parent in 10,000 rows of Parents table, take found parent and search for what kids this parent has in 10,000 rows of Children table. I search twice in two sets of 10,000 raws each.

Case No. 2. 1 tables of 20,000 rows (Parents and Children put together making People table)

I search for a parent in 20,000 rows of my People table, take found parent and search for what kids this parent has again in 20,000 rows of my People table. I search twice in one sets of 20,000 raws each.

So, technically I go through more searching in Case 2, but on the bigger scale it should not make a difference how many rows I go through (search is a P problem, there is a limit to its difficulty).

@emmanuel @josh

Could you help us to establish the truth here?

Does it matter how many tables we have?

What slows down things:

a) is it complexity of a search (i.e. number of relationships between what we search for, such as quick when we search for a direct child record, slower when we search for great-grand child)?

b) quantity of data?

c) width of tables (numbers of fields, where the more fields, the slower the search situation is true)?

Please, could we have some technical clarity on these matters?

Again, I have one table with about 50 fields. If I was to split this table in “Types of Things” I would would end up with 20 tables, 45 fields each.

I trust forum is a nice place but we are talking weeks of changes just because one guesses some method is right while another’s guess is opposite.

Thank you in advance!

Many of more advanced developers may benefit from clarity of what is the optimal way of structuring data.

That is a really interesting question.

Assuming you have them as list fields, and set up to be a datatype of elements …

We know that Bubble pre-fetches linked table data (which is one reason that using native bubble table links can be faster).

But as to whether the “tables” in Bubble are real or virtual, or if that is quicker, who knows.

1 Like