Bubble.io Workload Units Explained: How to Optimise Performance Costs
Workload Units are Bubble’s server computation currency. Poorly built apps generate significant overage bills. What consumes the most WUs, how to audit your app’s consumption, and the four architecture changes that reduce WU usage immediately.
The Currency of Bubble’s Server Resource Consumption
Workload Units (WUs) are Bubble’s measure of server-side computation. Every database query, every API call, every workflow action consumes WUs. Each plan includes an allowance of WUs per month; consumption above that generates overage charges. Most well-built Bubble apps consume WUs well within their plan allowance. Poorly built apps — particularly those that use :filtered by or perform live count queries on dashboard render — can generate significant overage bills. Understanding WUs is the key to keeping your operational costs predictable.
The High-Cost Operations
| Operation | WU Cost | Architectural Alternative |
|---|---|---|
| Database search (all records, no constraint) | High — scales with record count | Add search constraints; never scan entire tables |
| :filtered by expression | Very High — loads all records then filters | Replace with search constraints (WHERE clauses) |
| Live count query on page render | Medium per query; multiplied by page loads | Denormalise counts; read pre-calculated fields |
| Recursive API workflow (per iteration) | Medium per loop | Batch operations to reduce iteration count |
| External API call | Low — fixed per call | Cache API responses; don’t call on every render |
| Simple database write | Low — fixed per record | No alternative needed; writes are cheap |
Finding the Expensive Operations
Bubble Settings → Usage → Workload. This shows your WU consumption over time. Look for: high baseline consumption (high even with low traffic) and spikes that correlate with specific features being used.
Use Bubble’s server log to trace which workflows and pages consume the most WUs. High-traffic pages with multiple database queries on render are the primary suspects. Dashboard pages with count queries are almost always the biggest consumers.
// Use Ctrl+F in the Bubble editor to search
Search term
: ‘:filtered’
// Every result is a WU waste candidate
// Replace each one with a search constraint
// Before (expensive):
Search for Tasks :filtered by status = Active
// After (efficient):
Search for Tasks [status = Active]
Text
: Search for Tasks [workspace=X, status=Active]:count
// After (free — reads pre-calculated field):
Text
: Workspace’s active_task_count
// The active_task_count field is updated in every
// task creation, completion, and deletion workflow
The High-Impact Fixes
Replace every :filtered by
The single highest-impact WU reduction. One :filtered by on a 10,000-record type consumes as many WUs as 10,000 individual record reads on every page load. Replace with search constraints and WU consumption drops immediately.
Denormalise all dashboard metrics
Count queries that run on every page render are the second highest consumer. Moving counts to pre-calculated Workspace fields converts a server computation on every render to a single field read.
Cache API responses
If you call an external API to display data that rarely changes (weather, exchange rates, public data), cache the response in your database and only refresh it every hour or day rather than on every user request.
Build Your Bubble.io App With Expert Help
Pakistan’s leading Bubble.io development team. Multi-tenant SaaS architecture, Stripe billing, and full product builds done right from day one.
