Speed is an issue


I went so far without coding, and built a big part of the Quality, Project and Office Management System for my company.
While there are still many functions I want to implement, learning better about APIs, the issue is the speed.

The overall experience is frustrating. I am using repeating groups almost everywhere. I tried to limit the use of extended vertical scrolling (that created infinite wait time in nested RG) and almost removed all the :filtered functions. But still the webapp is becoming slower and slower.

I am not even sure that if in case we are going to pay for a dedicated server we are going to to improve it.

Among the general slowness, one page is “ridiculously slow”, almost 10 minutes!
I explain now this specific page as critical example.
This is a report page that using 3 nested RG, searches among 2 or 3 different data types.
Here I completely removed all the :filtered, it’s on “search of”.
here the code of this page:

In shorts:
This is what I want to get. A table that shows for each month and for each employee, the following infpormation:

  • how many hours are available (search of working hours per day of the employee * working days in the month - approved holidays)
  • how many holiday booked (search of Approved holidays of the employee, in the related month)
  • Hours booked in all the projects (these data is presented in many different way, but is based alsways on searches on the same type of data (“Labor Cost”) that includes field such as: employee, month, project, hours baseline, hours projected)


one more thing: either with Opera, Firefox and Chrome, when the editor opens it start to use up to 2.5 GB! Is that normal?

Any help is appreciated.




Your design here is very complex. Your doing some searches in the page that rely on 4 different searches in your search parameters, and this for 3 different text elements in each cell of a repeating group…

We do a lot of things to try to optimize this behind the scenes, but at the end of the day, if you need to complete 3 searches consecutively to start the one that displays data (and multiply this by the number of cells), that will take some time. If you were coding your page by hand with similar searches and data flow you would probably see something similar.

I recommend you read this thread, and try to think of a data structure that is simpler, by saving data on the object instead of searching for them for each search parameter.


@sergio.rufini, thanks for sharing. I know how it feels to spend a lot of time building something and have it feel like it’s not working and is, perhaps, impossible to have it work the way you want. That said, it’s important for members of the community to share there experience, both so we can all learn from them and so we can help one another.

In your specific instance, it sounds like the root problem is the RG within an RG within an RG. Bubble’s approach to loading an RG’s within an RG in painfully slow, and have 3 layers of RGs is exponentially slower than 2.

I’d look to see if there’s a way to restructure the logic so you’re not using nested RGs if at all possible. 4 Specific ideas:

  1. If possible, just simplify the logic. (sounds like you’ve already done this and more improvement may not be possible)
  • Sometimes you can add the ID of other tables to the current table which means you can cut out the “search for” logic within queries – this really helped us improve our performance. It’s considered bad practice among database professionals to duplicate fields, but it works really well for improving Bubble’s performance.
  • Add another table or two to your database that stores data in a way that won’t require you to use as many nested RGs.
  • Add a workflow that calculates these numbers ahead of time (perhaps it updates each day or each hour). Store that information in a table. Then, have the UI grab the data directly from that 1 table.

Keep at it, and let us know how it goes.


Hi Sridharan,

thanks for taking time to give your suggestion:
I am actually very excited about what I have accomplished with bubble. Something I would have need months of briefing with developers, and the money to pay them. The “magic” skipping these intermediates and creating straight out of my head was thrilling. And is a little frustrating once you get there, and see people hating you because it is soo slow. As QA manager I try to engage people in using all the tool help me to comply to our standards and the slowness doesn’t help :(.

Here my answers:

  1. I already changed a lot, in order to eliminate all the needed :filtered functions. Don’t know how to improve even more.

  2. Can you elaborate better? I am not sure I understood.

  3. I tried but without success. But not sure I did it right. Will think about it.

  4. Yes, I know. This is my plan B. If in the next days I will not find a better solution, I will try to learn better the scheduled API and try to implement it.

Despite this terrible and very special page, the whole platform is quite slow. Will it improve in the future? How can I know how much will improve by having a dedicated server?

Thanks again



Glad to hear that Bubble is generally working well for you. It’s definitely a game changer, enabling many entrepreneurs to build things that wouldn’t be possible without it. I’m also a big fan.

I’m not on the Bubble team and haven’t signed up for a dedicated server myself. That said, based on my understanding a dedicated server helps speed things up if the slowness was the result of too many people hitting your app at once. However, if the slowness is based on the architecture of your app, then a dedicated server won’t help much.

I also don’t have any inside info on future performance improvements. That said, it sounds to me like the Bubble team realizes this is a material constraint / challenge for many of their customers, but I suspect the engineering required to “solve” this is considerable and will be implemented in increments over multiple years.

@kramwe, can you provide a better explanation of my suggestion #2 from above? I know you’ve implemented this more than I have. Thanks.

1 Like

@sergio.rufini. hi.

We’ve found that nested “do a search for”s are particularly slow. While it’s typically frowned upon to duplicate fields in a database, we decided for performance reasons, we’d include the unique_id from the parent and grandparent tables in select progeny tables thereby reducing the extent of nested searches in our app. Pages that once took nearly 1min to load are now <3sec.

Specifically, this is here’s what this looks from a database-perspective.

Say you want to modify the parent table value where grandparent unique_id = 123.

Do a search for “Parent”
Grandparent = Do a search for “Grandparent”: first_item
Unique_id = 123

Now, you’ll eliminate the nested search
Do a search for “Parent”
Grandparent_unique_id = 123

If you do this throughout the page and extend it to Child-Grandparent tables, you should see the page load is considerably faster.



We follow something similar to above suggestion by @kramwe

Instead of Grandparent_unique_id, we have ‘list of parents’ in the Grandparent object and ‘list of Childs’ in the Parent object.
That helps us eliminate searches altogether in the pages.


Although I have no data to back up the speed, in terms of simplicity that is how I do updates on 1:Many situations.

1 Like

It managed to avoid another search in a search. Maybe there is an improvement, but I found that the real bottleneck here could be this:
I am creating a table that depends on months/year.

  • Since there is no general month source table, I create a “Month Table” where I have listed Date, month (integer) and year (integer).
    -Since there is no function to compare two data against the same month+year, I have to search in each table all the Labor Time that have a month and a year = to the current month in the upper RG.

This comparison creates the big bottleneck in all my tables, since all around my application I haved many tables of date: Timeshees, Budget of a project, Reporting.

Any idea on how to improve this?


Hi there,

It happens to me as well man and as you said it´s a pain in the …

We´ve gone through all the possibilities around how to load RG faster and contacted the best programmers (@sridharan.s is one of them) and in the end it seems that it´s a Bubble limitation.

We´ve been trying other approaches on how to design, what to show, using workflows to load on page load, hide and show an RG when it´s loaded, … but nothing.

So for now the only thing we can do is wait to see if things get better any time soon. They say they´re working on it and we trust it will get better since Bubble is awesome but it seems there is no specific timeline here.

So sorry to tell you but we´re having the same issue here.

Anyway, if you find some gold under the ground regarding this issue please let us know. I´ll do the same.

1 Like


I can go on with this particular page at such slowness for few months still. But if we want this to become a commercial product in the next year, we need to know that we are investing in the right tool. Otherwise it will stay I great prototype, but will need the money to pay developers… :frowning:


Bubble is such a powerful/ flexible tool with an insanely short learning curve, I don’t think investing time or money is ever a wasted investment to prove your model or test your product.

But I do think the responsibility is ours to make sure we are building products that are lean and optimised.

Just as Devs look to best practices and lean approaches when programming with code.
There is only so much architecturally the guys can do.

I haven’t experienced the lag that some users have expressed.

1 Like

I don’t think the time so far was wasted. ON the contrary, without bubble it wouldn’t be possible at all! So, all the credit for that.

I am trying to understand how much improvement I can add by organizing better the data, because as it is now, it cannot become a SaS product outside our company.

I removed all the nested search of but of course not the nested RG. Every Labor Time data type has to be searched against parent employee, parent month and parent year. this brings still to several minutes…
I cannot see a better solution (unless plan B, use scheduled API to create the report before).

I came to Bubble after building a product comp in Filemaker and being frustrated with a similar speed problem that you are having with Bubble.

As I rapidly recreated my prototype in Bubble (awesome program!) I realized I was asking for too many calculations at once and needed to break up when the math was being executed. So I redesigned my workflow and switched to much more “indexing”, or storing of calculated results ahead of time where customized math is not required. I identified the minimum calcs that were needed to provide the custom result for that user and set up input change trackers to pre-calc everything else. The result is lightning fast results. Really fast!

I also added a few more “page turns” to give the program a bit more calc time. Users expect a slight delay when there is a screen change.

Not sure if this helps, but thought I’d share anyway.

Good Luck.




so I tried to reduce the “live” search and calculations:

All the “search of” are performed by a scheduled API and stored in a new Type “12M report”.

This type has two field that work as index:
User, Month
and other fields that store all the calculated values I need to show in the report.

Problem is, in order to show, I still need a nested RG in order to create a table (horizontal for MOnths, and vertical for users).
This RG is still crazy slow to run… :frowning:
I really don’t know how to make it even more simple than that!
Something must be done wrong? Any hint?

HEre the code example:



Hi! The bubble isn’t work now. I can’t add data in my app. Bubble shows alert about technical issues :frowning:

Guys? Anyone?

Appreciate any help, thanks.

I tried clicking the link to your app but it forwarded me to bubble.is/home – is your app public?

The app is public… I tried again…

It still takes me to bubble.is/home for some reason.