What workload units measure
Bubble bills application work in workload units (WU). Database searches, returned data, file operations, workflows and API calls all contribute. For an app owner, the useful question is which operations repeat most often and how much each one does.
A large database does not automatically make every search expensive. A screen that repeatedly loads more records than it needs can waste work even in a small app. Start with the workload dashboard and a real user journey, then inspect the operations behind it.
Three drivers of workload
- Complexity
- Repetition
- Data returned
Start with searches and the data they return
A search should return the records the screen needs, with constraints applied as early as possible. Advanced filters and nested searches can add work for each row. Where a standard “Do a search for” constraint expresses the same condition, use it and compare the result in the dashboard. Bubble’s search guidance explains how returned data and nested expressions affect usage.
Reusing a list already loaded on the page also keeps the logic easier to follow. If a repeating group contains the filtered orders, another element can reference its “List of…” instead of defining another search for the same purpose. Check the actual queries before assuming identical expressions always create separate requests.
Look closely at searches inside repeating-group cells. A row that performs its own lookup can multiply the work as the list grows. A direct relationship or one shared query may provide the same data with fewer operations.
Keep temporary state and stored data separate
A selected tab, an unsaved filter or a temporary calculation belongs in custom states when it only matters to the current interface. Creating a database “thing” for each of these values adds writes and cleanup work. Data that must survive a refresh, be shared or be audited still belongs in persistent storage.
Database structure matters because it affects what each record returns and which lookups are needed. Splitting large, rarely used text from frequently displayed fields can help. Adding more data types by itself is not an optimization: extra relationships may introduce extra queries.
Counts and totals deserve the same attention. If the number must be current, calculate it from the relevant records. If it changes slowly, store the result and update it when the underlying data changes. The update rule is part of the feature; otherwise a cheaper total can become a stale total. See Bubble’s optimization checklist.
Reuse work that is already done
Repeated work
- Search again for a list already on the page
- Write temporary interface values to the database
- Recalculate a slowly changing total on every visit
A smaller amount of work
- Reference the existing data source
- Keep temporary values in custom states
- Update a stored total when its inputs change
Make workflow frequency visible
“Do when condition is true” and “Do every X seconds” are useful, but a small operation repeated continuously can dominate the bill. Check when each event fires and whether it needs to run again after the work has succeeded. Recurring backend jobs deserve the same review.
Within a workflow, Result of Step X makes a dependency explicit and reuses a result already produced. It does not make every independent action synchronous. Likewise, changing several fields in one save can avoid the repeated writes that automatic saving on every edit might create.
For bulk work, choose the method by what the operation needs:
- Make changes to a list can suit a straightforward update to a set of records.
- Schedule API workflow on a list suits per-record work that can run independently.
- Recursive workflows are useful when sequencing, pauses or a stop condition are part of the job, but each rescheduling step adds work.
- The Data API can suit imports and external integrations. It is not automatically cheaper once a list reaches a particular length.
There is no universal 20-record or 50-record cutoff. Bubble’s own comparison of bulk operation methods shows why the workflow itself matters. Compare completion time and WU on a representative batch.
Frontend work can still use the server
A frontend workflow may hide an element entirely in the browser, then update a database record on Bubble’s server. Its location in the editor does not make all its actions cheaper. Bubble distinguishes client-side and server-side processing by the work each action performs.
The same applies to page structure. A single-page app can reuse data between views, but can also load too much at the start. Several pages can be efficient if each loads only what the user needs. Inspect searches in conditions, hidden sections and page-load events before changing the whole navigation.
Measure one change at a time
- Find expensive operations
- Remove repeated work
- Check app behavior
- Compare dashboard usage
Decide from the dashboard
Record the usage for one representative task, change one cause of repeated work and run the task again. Check that the result is still correct, permissions still apply and users are not seeing stale data. Then move to the next expensive operation.
We offer a free consultation to review your Bubble app and suggest where workload can be reduced.
