What is a Bubble Workload Unit?

A Workload Unit (WU) is Bubble's metering currency for backend compute. Every page load, workflow run, database search, API call, and background task consumes WUs based on how heavy the operation is. The unit cost varies — a simple field read costs a fraction of a WU, a complex multi-table search with calculated fields can cost dozens. Bubble doesn't publish a unit-cost table per operation; the only way to know is to run the app and watch the meter.

What does Bubble charge after free WUs?

Plans include a monthly WU allocation. After that, overages cost $0.30 per 1,000 WUs. Starter ($29/mo) includes 50K WU, Growth ($119/mo) includes 500K WU, Team ($349/mo) includes 1.75M WU. Run past your allocation and the meter adds the overage to your monthly bill automatically.

What causes Bubble WU bill shock?

Three patterns. (1) Search-heavy pages that re-search the database on every interaction instead of caching results. (2) Background workflows that run more often than needed (every 5 minutes when every hour would do). (3) Sudden traffic spikes from a HackerNews post or TikTok mention that 10x the normal page-load volume overnight. All three can blow through a monthly allocation in a single afternoon.

When do I outgrow Bubble's WU model?

Run the math: if your overage line item is more than 30% of your base plan cost two months in a row, the pricing has stopped fitting. At that point you have two choices: optimize your Bubble app's WU usage (real engineering work, often weeks), or move the WU-expensive logic out of Bubble onto a backend with predictable flat-rate pricing. The second option is usually cheaper if you're past the 50K-MAU mark.

Can I tell what's consuming my WUs?

Partially. Bubble shows a WU consumption dashboard but it groups by workflow and page, not by individual operation. Finding the worst offender usually requires manually disabling features in dev mode and watching the meter, which is slow and disruptive. The better signal is your monthly trend: a steady climb that outpaces user growth means you have a per-user-WU problem, not a scale problem.

Bubble's Workload Units Are Eating Indie Hackers in 2026 (And the One Number to Watch)

Bubble's pricing change moved everyone to Workload Units in 2024. By 2026, the bill-shock stories are everywhere. The pattern is repeatable. Someone ships a Bubble app, traffic ticks up modestly, the next monthly invoice has an unexpected overage line item, and they don't know what to do about it.

This is the field-notes version. What the numbers actually are, what burns them fastest, and the threshold where the model stops working.

The numbers, in case you need a refresher

Bubble's current plans bundle a monthly WU allocation:

Starter ($29/mo): 50,000 WU/month included
Growth ($119/mo): 500,000 WU/month included
Team ($349/mo): 1,750,000 WU/month included

Overage above the allocation is $0.30 per 1,000 WU. So an app that runs 1,000,000 WU/month on the Starter plan is $29 (base) + $0.30 × 950 ÷ 1000 = $29 + $285 = $314/month. The overage is 10x the base.

The trap is that 1,000,000 WU/month is not a lot. A moderately busy SaaS dashboard with 100 daily active users running 50 page-loads-per-user with 4 searches per page-load is at that level easily. The actions you build naturally and the WUs they consume are not the same shape, and the gap shows up at scale.

The three patterns that burn the most

1. Search-heavy pages

Bubble's database searches are the single biggest WU consumer in most apps. A simple "find this record by id" is cheap. A "find all records matching these 4 conditions, sorted, joined, with calculated fields" costs an order of magnitude more, and the cost runs every time the page loads or the user clicks anything that re-renders.

The fix is caching: do the search once, store the result in a state variable, reference the state variable instead of re-searching. This is real engineering work, not a config flip. Apps that grew organically without this discipline get expensive fast.

2. Background workflows running too often

Recurring workflows are the second-biggest. Bubble lets you schedule jobs at minute granularity, and the default impulse for a maker is to keep frequency tight (every 5 minutes feels safer than every hour). The WU bill follows. A workflow that runs every 5 minutes is 8,640 invocations a month. If each invocation is 50 WU, that's 432,000 WU — the entire Growth plan allocation, on one workflow.

The fix is to ask: does this need to run every 5 minutes, or every hour, or every day? Most jobs that look real-time can run hourly. Reset the schedule and watch the bill drop.

3. Traffic spikes

The third one isn't a pattern you cause, it's one that happens to you. A HackerNews post, a TikTok mention, a Product Hunt feature. Your traffic 10x's for 48 hours and your WU usage 10x's too. There's no rate limiter — Bubble keeps serving the requests and the meter keeps spinning.

You'll see this one in the dashboard the next morning. The fix is partly architectural (cache aggressively, pre-render where possible) and partly contractual (Bubble's overage charges aren't capped, so a viral spike can produce a five-figure invoice in a weekend). Set a billing alert before you publish anything that might spike.

The line where the model stops fitting

The honest threshold: if your monthly overage is more than 30% of your base plan two months in a row, the pricing has stopped working for your shape. Three rough cases:

Under 30% overage: stay, optimize. Bubble's tooling for WU optimization is improving and the dashboard does show worst-offender workflows. A weekend of cleanup usually pays for itself for 3+ months.
30-100% overage: upgrade plan tier first. The included WU allocation scales faster than the base price, so moving Starter → Growth typically costs less than paying the overage on Starter if you're going to keep growing.
Sustained 100%+ overage: the WU model has stopped fitting. Move the WU-expensive logic onto a backend with flat-rate pricing. Don't try to "optimize your way" through a 2x overage indefinitely. The engineering time costs more than the migration.

What the migration shape looks like

"Move off Bubble" is usually the wrong framing. The right framing: keep Bubble for forms, admin views, and the parts of your UI that work fine, and move the WU-expensive logic onto a purpose-fit backend.

The common shapes:

If your WUs are burning on persistent state (real-time multiplayer-ish patterns, shared inventories, leaderboards), reach for a game backend or a managed KV store like BaseKV. The HTTP call from your Bubble workflow costs negligible WU compared to running the same logic inside Bubble.
If your WUs are burning on AI/LLM calls and metering, reach for a usage-billing platform rather than billing through Bubble workflows. You get per-customer cost tracking for free, which Bubble doesn't.
If your WUs are burning on background analytics or data pipelines, move those to a regular cloud worker (Cloudflare Worker, Lambda, hosted cron). Bubble was never the right tool for those.

The pattern that wins is composition: Bubble for the parts it's good at, hosted services for the parts that broke the WU model. You don't need to rebuild your whole app.

The one number to watch

Track overage ratio. Every month, divide (overage charge) by (base plan cost). Plot it. If it's flat under 30%, you're fine. If it's climbing, you have a leak. If it's above 1.0 two months running, the migration math has tipped.

That single ratio is more honest than any WU dashboard breakdown. The dashboard tells you what consumed WUs. The ratio tells you whether the pricing model still fits your business.