I’m curious how other Bubble developers approach database performance as an application grows.
For a small app, searching and displaying database records seems fairly straightforward. But once the database starts containing thousands or tens of thousands of records, I imagine things like repeating groups, searches, filters, and workflows can become more expensive or slower.
What practices have you found useful for keeping an app responsive as the amount of data increases?
For example:
Do you limit the number of records loaded into repeating groups?
How much do constraints and search conditions affect performance?
Is pagination preferable to loading larger datasets?
When is it worth restructuring the database?
Are there particular workflows or queries that commonly cause performance problems?
I’d be interested in hearing what approaches have worked for people who have built Bubble applications with larger datasets.
Just like any development process, you have to plan for it. Don’t use Advanced Filters, dont filter on data after all the data is downloaded. Use constraints. Use pagination. Those are the first thigns to come to mind. Keep data structure and data tables lean. I am sure others will have more tips as well.
Bubble can scale just fine if you know what you are doing.
In my experience, the biggest issue is not simply having tens of thousands of records, but how the app is querying and processing them.
I usually avoid loading a large dataset into a repeating group unless there is a real reason to do so. For lists, I prefer pagination or incremental loading, with sensible limits on the initial query.
Search constraints are also important. A search that can narrow the dataset down early is much better than loading a large set of records and then doing additional filtering or processing on the client side.
I also try to avoid putting database searches inside workflows that run repeatedly, especially when they are triggered by changes to a repeating group or by every keystroke in a search box. Debouncing searches and only running them when necessary can make a noticeable difference.
When the data model starts getting more complex, I look at whether everything really needs to be stored and queried as separate things. Sometimes restructuring relationships or keeping frequently accessed information closer together can reduce the number of searches required.
For larger datasets, I also pay attention to backend workflows. Processing thousands of things in one workflow is usually something I would avoid; breaking the work into smaller batches and processing it asynchronously tends to be more reliable.
So I wouldn’t say there is one magic number where a Bubble database becomes “too large.” The query patterns, number of searches, frequency of workflows, and amount of data being returned usually matter more than the raw record count.
If you want to discuss further, feel free to DM me
First thing : use the App metrics page to identify heavy workflows. You can be surprised with some WF you thought were heavy, when in reality they are not. And some WF you thought were light, but are not. Or are called so many times they need some workaround.
When looking is a repeating group is empty or not, don’t go for “List of thing:count != 0”, but “List of thing:first thing:is not empty”
Use UX strategies to load less things. (don’t load stuff unless the user really need it, add “Load more” buttons for example, or use other UX strategies)
Use satellite Datatypes for faster and smarter filtering/sorting.
Add Datafields for faster and smarter filtering/sorting. (example, on a User, add a fields that concatenates “Firstname” / “Lastname” / “email” as a text field, for easier “Do a search:countain”
@seo.nucot the Bubble database will work efficiently into the millions of records.
The only query that is not handled efficiently (and is borderline impossible at scale) is many->many lists (like this list of tags match this list of tags)
The main mental model you can think about when designing your database is reducing the amount of “jumps” between data to get what you’re looking for in searches. Bad examples would be;
The trade-off in your design will be managing to meet your feature requirements with Data Maintance etc. So you can think about searches that are running all the time needing updates, whereas searches running once daily can deal with the inefficiency.
All of these are good tips. Another tip to keep your page feeling responsive when you have to do some complicated operations are to do them on the backend. Create an API call in the API connecter and connect it with a backend workflow. Create a call that passes some information on the frontend, allow the backend to do the complicated task, and have it return the result to the page. Of course you’ll want to authenticate the API call with a user specific generated token. This keeps pages feeling responsive when you have complex operations to run.
This is something I’ve been thinking about with a project I’m currently building
I actually ran into a performance issue because, then myself including the team found out that one workflow was doing too many searches. At first it didn’t look serious because the app was still small, but once more data started coming in, the difference became noticeable.
A few things we’ve learned with the build , and now we pay more attention to them, are:
Keeping the original search as narrow as possible instead of pulling a large dataset and filtering it afterward.
Avoid loading more records into a repeating group than the user actually needs at that moment.
Watch searches that rerun frequently, especially ones connected to inputs or changing conditions.
Break larger backend jobs into smaller batches rather than trying to process everything together.
If the same complicated searches keep appearing everywhere, that’s usually when I’d start questioning the database structure itself.
One thing I’ve started realizing is that the total number of records isn’t always the biggest problem. Sometimes it’s simply how much work one page or one user action is asking Bubble to do.
(