The Ultimate Guide to Bubble Performance - the new edition is out (now 210 pages!)

Hi Peter
Interesting that on my Android phone in Kindle whenever there are two ffs the 1st f is blank see screen-shot example below. Not a biggie but I thought I’d let you know.


Thanks for writing a great book!

I am struggling a bit with the “Link Data Type” discussed on pp. 116-117.

It sounds kinda like a “Thing Dump”, where you might put a bunch of lists of things (presuming the lists wont exceed 10,000 units)…

…but I am not too too sure.

Using your project management example, would you create “Project” as the “Link Data Type” and then dump the tasks, users, etc in that?

This seems like a super critical point for my project (which will involve some project management funny enough!) but I am not quite getting it in the same way that I understand Search, Content, and Merged Data Types.

I think it is because you gave good examples of those with with Client Vendor and Travel examples, but didn’t directly cover the Link Data Type.

An example of how this would work would be loooooooovely! <3



1 Like

FYI. Spotted a typo.


The purpose of the Link Data Type is really to bind things together using one data type and one field on each type you want to connect.

There are a few ways that could be done, and it would mostly rely on how you want to search for and display the data later. Let’s take the example from the book, and link Projects with Tasks and Users.

Using a Search data type
If you already have a Search data type, you can use that to link Data Types together using a list field. For example, on a Project, you may have a field containing a list of Searches. In that way, a single field can store multiple data types that you can filter as needed (i.e. showing only linked tasks or only linked Users.

Using a separate Link Data Type
If you need more advanced linking (such as adding data to the link itself), then a separate Link Data Type can be useful. An example of adding data to a link could be adding a User to a Project, and then saving some sort of description on that link (describing a User as Project Manager or saving the date when the link was created). You could still use the Search data type to reference the Task or User that you want to connect with the project, but the Link data type would only be created when needed. The Link Data Type can be searched for (removing the need to store it in a list), and allowing you to use Privacy Rules on it.

I may add another example for the Link Data Type at some point if that was unclear, but I’m hesitating a bit since there’s such a wide range of possible scenarios that would require different setups. It may be that the mention of them didn’t really belong in the book in the first place, happy to take feedback on that point.

Hope that cleared it up at least a little bit.

Thx! Strange thing about the Kindle bug - I assume that’s happening when the PDF is converted to MOBI.

1 Like


Thank you for going into some detail!

To start off, you wrote the book, so whatever you feel belongs in there is what belongs in there…

…however, linked data types seem like a powerful concept that would be valuable to understand.

I have to admit, just adding in the Search data type into the Linked data type is causing some confusion for me.

Is there a Performance or Privacy Principle that wraps up when Linked data types(LDTs) should be employed?

eg. "Use LTDs when you want to prevent lists from being downloaded.

ie. you have Project-Search, Project-Data, Project-Links as 3 separate data types all relating to projects.

Project-Search is the basic info.
Project-Data is the meat
Project-Link contains all the linked lists etc…

I don’t know if that is how it should work at all, just making it up based on my understanding from the rest of the book.


I just want to share the great experience I had with Gumroad support.

I decided to buy the book and paid with Apple Pay. There was, however, an error msg and the book did not download, only the money was taken from my account.

I contacted Gumroad support and got a reply within a minute with a concise explanation of the glitch, informing me that it was solved, and the link to the book just in case.

Wow, that must be some sort of a speed record for solving an issue. Thank you, Gumroad!

Let me start now with the Ultimate Guide. It’s sure what I need on my Bubble journey.


Bought it - love to support bubble & its Community :partying_face:



@anon10873777 The way you describe the three different data types makes sense, but I have a few comments:

  • I’m describing two kinds of Search data types in the book: one is the general practice of keeping any data type that you need to search for as light as possible, and potentially setting up a Data Container (Project-Data) as a satellite data type to contain the heavier fields. Which one is the “main” data type is really up to you - but personally I would see the Search Type as the main and the Data Container as the satellite.
    The second kind of search type is the combining of several types into a single searchable data type, with the typical use case of app-wide searching for “anything” (in the way you can search for documents, spreadsheets and presentations in the same search bar in Google Drive for example). These are of course also lightweight, only containing the data needed for 1) searching/filtering/sorting and 2) displaying the results.
    Sometimes you may find it necessary to use both of these search types in the same app.
  • I don’t really see the Link Data Type as a container for long lists of things (although I’m sure in certain scenarios that’s the right way to set it up), but as a Thing created for each link that you need. So linking a Project with a Client and a User for example, would require creating two links. But again, this caters to a very specific scenario where we want a Project to be linkable to several other data types and include information about that connection (description, date, etc). Privacy Rules come into play here for sure, but again is so dependent on the requirements of your app that it’s hard to set any general rule of thumb for it.

For Link Data Types, that would require going over some questions:

  • which data types will I be linking?
  • should links be stored in one field or can I store them in several (where you may not need a Link Data Type at all)
  • will I be using Links as a search constraint (searching for all Projects for a specific linked Client for example)
  • what kind of information does that link need to store?
  • how are those links affected by privacy/security?
  • how will they be displayed, if at all?

Different answers here can require pretty drastic changes to how these links are set up, so again it goes back to planning, understanding the requirements of each Data Concept and not getting Data Concepts and Data Types mixed up.

Overall, an important point regarding the whole book is to keep in mind not to over-engineer stuff: the book presents examples to try and illustrate how Data Concepts and the actual Data Types can be very different things, not to try and convince you that the examples are best practices that all apps should implement. The most important point in that chapter in my view is to take your Data Concepts through a process that lets you define their requirements and structure the final Data Types based on that process.



I think a course is in order to be recorded on how to do all of this… :slight_smile:

(Would actually be really valuable to see visually how to set all these things up.)

I saw you do some lessons for companies so will discuss with partner about inquiring about those as well.

Thanks a lot once again for the in depth replies!

I am going through the Data Concept → Data Type exercise now.



Hi @petter, fantastic book! I learned so much - thank you.

I wonder, is there a practical limit on how many fields a data type can have?

I’m building a rideshare app, and the biggest data type is Trip where I now have about 200 fields – I want to record many different aspects of each Trip (time, GPS, reviews, etc).

Is 200 too many fields on a data type – will Bubble become slow when my app is live? (In which case I would create additional data types to split up the fields.)

Thanks for your help!


1 Like

Hey @greg,

There’s ready no sure-fire way to say exactly when you have too many fields, as it depends on different factors: what do the fields contain, what are you using the data type for, etc.

200 fields is certainly a lot, but I can’t say if it’ll slow your app down or not. I’d recommend looking at the chapter on database structuring where we look at data concept requirements to try and determine if you’ve set it up in the right way. Relevant questions in your case would be:

  • Do I need to frequently/quickly search for this Thing?
  • Do I need all 200 fields on every instance I’m loading, or just in specific cases?
  • What’s the total data weight on the Type (are the fields containing structured or unstructured data)

It may make sense to set up a satellite Type for searching for example, if you’re planning to use that frequently. The good thing about a Search satellite type is that it’s pretty easy to set up at any point later. You may want to hold back that decision a little bit to see if the fields actually affect your performance or not - if searches do become slow and/or the download too big, you can set up the search satellite and create one for each record using a recursive workflow. If they work just fine, then there’s no reason to.

If you’d like to test it a bit before going live, you may also want to generate a bunch of records with random data (again using a recursive workflow to generate as many as you need) and do some testing on the performance side. If it’s starts slowing down quickly, you’re better off knowing before you have live users.

@emmanuel said in an panel talk on the Zeroqode no-code conference that they’d had users adding thousands of fields to a data type. Initially they were hesitant how to react, as it’s not really good database practice to do that, but from my understanding, they decided that “we need to facilitate for whatever our users are actually doing, not what the should optimally be doing” (I’m paraphrasing here) - I don’t know how that translated into actual optimization in Bubble to handle that many fields, but it’s an interesting statement nonetheless, and may be worth checking out with Bubble support. Let us know if you do!

Hope that helps!

I have a guide on setting up recursive workflows on our website if you’re not familiar with this.



I’m working on bubble app for making like uber eats app

I wanted to make real time tracking of driver in customer page.

Is that feature available in your plugin, or any suggestions for doing that?

Kindly help me out regarding the same.

Thank you

Hi @petter thanks for the updated version. I enjoyed the first version and your updates were perfectly timed for my own app’s evolution.

I have a question about the dataType option set on page 137. As you include the dataTypes for GEO and POI in a single option set, would you say that you are inclined to support a single/unified option set that hosts all dataTypes across the app? Prior to your update I had started to make similar dataType option sets for each of my data types. To use your examples, I would have had an option set for POI data types and another for GEO data types, and so forth. My ‘siloed’ approach made sense to me as these options wouldn’t be used across multiple data types, and if they did I could add a new field.

For example, i’m making a financial app. I have “Assets” and “Vehicles” and “Markets”. Assets can be grouped at two levels: I have an option set for assetClass that every asset will have, and an option set called assetType that breaks down each assetClass even further (where relevant). Each assetType references its ‘parent’ assetClass as an attribute. Vehicles follow a similar structure. No asset ever needs to reference a vehicle-specific option set, nor vice-versa. However, a Market is a unique data point that references (is made up of) an Asset and a Vehicle (and some other data types), and therefore has reason to reference both of their relevant option sets (assetClass, [assetType], vehiclePrimary, [vehicleSecondary, {vehicleType, (vehicleStyle)}]) - I hope that those consecutive brackets help to detail the depth/detail/dependancies.

Do you think that I should place all of the data-types (options) in a single and much longer option-set? Will this help with searching? Or is my approach good given my use case? As they’re currently structured, I feel that these groups (option sets) will work well as user-operated filters for tables (repeating groups), filters that only appear when the ‘parent’ option is present. If you agree with my approach but also feel that it may hinder searches, is there a way to ‘solve’ that problem simply?

Thanks in advance, I hope that I didn’t ramble too badly.


1 Like

@petter Thanks for the book.
Typo at p. 123


1 Like

Sounds like a great book, but I would really like a paperback version. I will buy ebook now, because I need it so badly, but will also buy paperback when available. Putting it from ebook onto Amazon Createspace as a paperback is quite simple. Dave Wommack. 619-255-3876.

1 Like

@petter Hi Petter, I have a request about your website interface…
Right now, it’s not accessible for automatic translation tools.
I’m working in Japan and my colleagues cannot read English. Would be great to fix the website so that Google Translate can pick up the rest of the page.

This is what it looks like when running the translation:

The title gets picked up correctly. But the actual interesting information does not.
Can you have a look?


1 Like


Thanks for getting in touch.

I’m not completely sure what I’m looking at. Is this a browser preview of the Gumroad pdf?

1 Like

This is in the browser, after clicking on Read.
The url starts with

Thanks for replying so quickly :slight_smile:

Ok, I see. This is Gumroad’s built-in book-reader, so there’s not much I can do to change it unfortunately.

I may be able to run the original editable document through Google Translate and create a PDF for you, but I have to warn it will probably be a far from perfect translation. Let me know if you want me to check that possibility.

I’ve looked into getting it properly translated to Japanese, as it’s the most requested language outside of English, but I can’t say if or when that will happen at this time unfortunately.

1 Like

Thanks @petter

Yes, that would be great, even though the automatic translation may not make sense from time to time, that would already be helpful for the colleagues (I hope).

And indeed, Bubble is taking off in Japan. And the lack of Japanese resource on it shows that there’s a real market opportunity here. Especially as most Japanese people do not speak English, so it’s usually a closed market when it comes to dealing with information and knowledge.

I’ll be waiting for the auto-translated PDF in the meantime, thanks a lot, on their behalf. :slight_smile:


1 Like