I’ve spent a ridiculous amount of time learning and working with Bubble, thinking I was finally seeing the light at the end of the tunnel. Everything was going smoothly until I hit the dreaded “workload” issue.
Currently, I’m using an external database (Supabase) to try and speed things up, but the performance is still awful. it’s soo slow and laggy. I’m pulling just 20 items from the database, saving them in a simple custom state and displaying them in a custom state and there’s consistently a one-second lag on my screen. This is unacceptable for a modern platform!
The reason Bubble is so slow when pulling data from external databases is obvious—it’s pushing you towards using their internal database, so they can overload you with workloads. It’s a blatant business model. It’s just very satanic if you think about it. The whole workload business model is honestly the dumbest ideas Bubble has ever come up with. It’s just incredibly counterproductive for anyone trying to build serious, scalable apps.
The other day i saw a dude just making a simple api call and it cost 62 workload units , unbelievable
Everything costs workloads. Conditional statements? Workloads. Navigating a page? Workloads. Searching the database? Workloads. Api calls? Workloads.
So what’s next? Moving your mouse? Breathing? Is that going to cost workloads too?
If you’re going to use an external database, don’t use Bubble. Bubble’s a bad front end, bad backend, and a great full stack platform.
So, would you like to share some more about your app so the helpful people here can give you some advice on optimising it, or are you just looking to vent?
Bubble is really good at what it is. They have to make money just like we’re trying to make money so they can continue to operate so it’s only fair. (Maybe if one day they implement their own payment system, but one can dream)
Now with Bubble you have to really prepare and lay a roadmap of what you plan to do and adjust accordingly, but that applies to any programming language. Chances are, optimizations can always be done to decrease WF usage, just like with any other language there’s always 100 ways of doing 1 thing but there’s always a best practice, so if you or anyone needs help/tips someone is always available to offer their insights.
I’m facing an issue with a delay when updating a repeating group in my Bubble app.
Here’s my setup:
On the page load, I fetch data from my external database (Supabase) via API calls. Specifically, I retrieve a list of categories and a list of items.
I save these lists in custom states:
A custom state for the list of categories.
A custom state for the list of items.
On the next page, I have two repeating groups:
On the left, a repeating group that displays the categories.
On the right, a repeating group that displays the items based on the selected category.
When a user clicks on a category in the left repeating group, the items shown in the right repeating group should update to display only the items for that selected category.
The issue:
Whenever I select a new category in the left repeating group, there’s always about a 1-second delay before the items in the right repeating group update. The data is already stored in the custom states, so I’m not sure why this delay is happening. I expected the transition to be instant since everything is loaded in memory.
Sorry for my previous message, I was just really frustrated because this issue feels like such a big trap from Bubble. It just honestly feels like I keep hitting a wall.
I really appreciate the time and effort everyone puts into helping on this forum, and I would be super grateful for any advice or insights
If you used the native database, it would be going:
Browser
Bubble server
Browser
Seriously, don’t use an external database if you’re starting a new app on Bubble. Use a different front end if Bubble’s database + backend limits you.
If you share the expressions/filters for your two repeating groups we can help identify why there is most likely an extra API call being made back to Supabase.
i use OmniSearch for this very purpose. Pulls directly from the bubble backend via algolia or typesense without having to use bubbles crappy “do a search for” workflow.
Also to add, we live in an age of instant gratification where boredom is forbidden, so you must give the user something to look at when things are happening.
If the RG is loading, have an animation while it’s in loading state so they can visually see something is happening. Is it ideal? No, but your app feels dead when something is happening and there’s no visual representation.
I would also do as others suggested, use Bubble’s database and as much as you can, only load the data you need and keep it minimal.
Also, 1 second response isn’t really all that much, there are some functions in my app that take 5-10 seconds (For good reason, it’s planned!), so if you have no complaints from users about speed, then don’t worry about it. To me, it’s far more important what an app can do vs how fast it can do some things.
bubble saves a ton of developer time and is great for prototyping to get something up and running as fast as possible. Why even worry about scaling when most applications will never get a following? If you do get a following worry about the cost of scaling at that point.
Trying to use external storage to plan for scaling when you are just starting out is a foolish waste. Build a minimal application and get some users.
They said 3000 users with the same profile as what they have now would cost $539 per month, or $.17 per user. They estimated that higher usage users could cost $5 per user per month. Ultimately that seems like an incredible value. Especially if you have ever had to build an application from scratch and host it yourself.
If we ever get to the scale where the cost is too much that will be a good problem to have.
@georgecollier is correct to point out the informative insight of what is likely happening.
For help with some actionable insight, instead of (if you are) having the filtering take place on Supabase, move it to bubble since you already have both lists in your custom state.
Your rg showing products should be of that data type and source is the custom state that holds the full list, and then use a filtered operator after that and the category should be equal to the category selected by the user that comes from your custom state of categories.
That way you are just requesting the data from the supabase API and then not contacting them again. This may help save 500 ms in display time as it removes the need to run the API calls again.
You have to sit back and relax. Try to really understand what you need and how to structure it. For instance, in our case we know which 80% of fields is used by customers so we simply setup a view for those in Supabase and load in on loading the app in a custom state. If data needs to be updated we refresh the custom state.
Another important point is to use filtering and sorting from Supabase when you use data from that database. It is so much faster. So you request exactly what you need and nothing more.
When you have two states and you are sure they are both populated without complex filtering when using it in a RG it should be instant.
Good luck!
PS 1 second is indeed very slow but in most cases not a big issue when pulling in data. True it would be closer to 100ms on modern platforms but still it is not a big issue in most cases. Do not forget you can always distract a user with some animation and 2 seconds have passed
Yeah, the Bubble SQL connector is slow in my experience…
If you’re going to use an external database you also want to use an external Backend (which you already are in Supabase), so no need to have Bubble’s backend involved at all (as long as you secure/authenticate the Supabase APIs correctly, unless it’s public data).
So make the API calls directly to Supabase from the browser.
That said, if you’re going to offload both the database and backend outside of Bubble, all you’re left with is Bubble as a front end tool, which is arguably the worst aspect of Bubble, and there are far better tools available.
@georgecollier I’ve also observed API calls from Bubble API Connector to external backend (in my case to Xano) being very slow because it passes first through Bubble server.
For Xano specifically, the plugin by Eli Beachy should address this issue though, right?
There’s no way to call an API through the browser without Javascript. Maybe someone made a plugin for it so you won’t have to write your own script?
I’m not saying it’s easy but AI can assist to write a script for the fetch and returning data to Toolbox’s J2B elements. You can test a CURL call using Postman then get AI to convert that CURL to JS fetch, to start with.
Though there the issue of CORS…even then you can work around it with an intermediary like Cloudflare Workers. So Browser calls Worker to call the API and return data to Browser.
Again I know it’s kind of complex but the cost savings are more than worth it, especially at scale.
You can use a simple fetch call to make API calls directly from the browser (with some custom JS or a plugin).
You can also check the ‘Attempt to make the call from the browser’ checkbox in the API connector where applicable.
note: you cannot (and should not) make requests directly to a database from the front end. Database requests must be made from a server not a browser (hence the need for a separate backend).
it’s a rocky path! And I’m still a big fan of the Bubble front end but that’s another story.