Bubble Database and Workflows: How a Bubble App Runs Inside

Bubble (bubble.io) runs every app on two engines you set up without code: a built-in database shaped with data types, fields and option sets, and workflows that react to events on the page or on the server. The database is built on PostgreSQL, yet you never write SQL against it. Privacy rules decide on the server which records and fields reach a user's device, and they are the first setting to audit before an app takes real users. Every server-side step spends workload units (WU); a database search starts at 0.3 WU plus 0.015 WU per thing returned ^[1].

Data types, things and option sets

A data type works like a table, and each record in it is a thing. Every new app gets a User type with an email field and sign-up already wired, and every type carries Creator, Created date, Modified date, Slug and Unique ID fields on its own. Relationships are fields too. A one-to-many link is a field holding the other type; many-to-many uses a list field on both sides, with no join table. An app can hold up to 1,000 custom data types.

Two limits shape real designs much earlier. A list stored on a thing holds at most 10,000 items, and a search with sorting returns at most 50,000 things, so a relationship that keeps growing belongs in its own type pointing back to the parent. The Free plan caps the database at 200 things, while the pricing page lists unlimited things on paid plans. Values are not kept unique for you. A field such as an email address needs a workflow check before the write.

Option sets hold static data that rarely changes, such as countries or order statuses, and they load quickly because they skip the database. The price of that speed is visibility. Option sets and app texts reach the browser as plaintext, so an API key stored there is readable by anyone who opens the page code. Files follow their own logic: each is stored as a URL, and files uploaded through the editor are not covered by privacy rules.

Privacy rules: the gate that runs on the server

Privacy rules are conditions per data type that decide who can find things in searches, which fields they can view, whether they can open attached files and whether inputs can auto-bind. They run on Bubble's server, so data a user may not see never leaves it ^[2]. Hiding an element protects nothing. When Bubble loads a thing it sends every field the rules allow, not only the fields on screen, and with no rules at all the whole record can be read on the device.

Several settings deserve a deliberate pass. Since July 2026 each rule has a Constraint option; untick it and searches filtering on that field return zero results for users under the rule. Rules exist separately in Development and Live, so a fix reaches real users only after you deploy. When the AI Agent builds a data type it writes rules for it, and Bubble says to review them before launch. Fields withheld from the browser also cost less workload to send.

Here is why this matters more now. Bubble's preliminary root-cause analysis (November 2026) says an attacker got partial access to Bubble's production systems and some user data, including private plugin data such as credentials plugin developers had saved. It says the attacker also targeted individual apps through platform issues that reached stored credentials or data even in correctly set-up apps, and through app settings such as privacy rules that granted access; affected owners were contacted, and a final RCA will follow ^[3]. Bubble advises running the security dashboard on each app, reviewing privacy rules, marking API keys private and checking API Connector calls.

The dashboard starts on Bubble's Starter plan with five basic tests, and Growth adds advanced checks with unlimited tests. Its privacy rules checker scans every data type for publicly accessible fields, but it needs sample data in each type to report anything meaningful. Run it on Development before every deploy. It only flags problems. Fixing them stays your job, and Bubble's SOC 2 does not make your app compliant, as our Bubble review explains.

Workflows: on the page, on the server, on a timer

Frontend workflows stop when the tab closes

Each workflow has exactly one event and a chain of actions. Frontend workflows fire on page events such as a button click, and they run only while the page stays open; close the tab and an unfinished chain stops. Anything that must complete, such as recording a payment, belongs in a backend workflow on the server. Steps also run in parallel rather than waiting for one another. A search in step three may miss the thing created in step two, so point at the Result of step 2 instead.

Backend workflows, schedules and triggers

Backend workflows are off by default; you switch them on in Settings → API. Server-side work then starts in six ways: an API workflow called from your app or an outside service, the Schedule API workflow action, a recurring event, a database trigger, a backend custom event, which the caller waits for and outside apps cannot reach, and an in-app purchase event for native mobile subscriptions (the native mobile builder is labeled beta). Recurring events run daily, weekly, monthly, quarterly or yearly. Recursive workflows allow any interval but burn more workload, and apps created from July 2024 stop such chains after 10 iterations by default.

Database triggers fire on any change to a type, including a manual edit in the Data tab, and compare Thing before change with Thing now. They run with admin rights, so privacy rules do not apply inside them, and API workflows can be set to ignore the rules too. Use both sparingly. For bulk jobs, Schedule API workflow on a list runs items in parallel, up to 100,000 unsorted; in Bubble's informal benchmark of 100K runs it used about 12,000 WU against about 70,000 for a recursive loop.

Plan gates bite here. On the Free plan, scheduled and recurring workflows are marked Limited, and backend calls to outside services carry limits meant only for testing. Daily recurring workflows start on Bubble's Starter plan, which on the Web tab is $32 per month billed annually or $39 per month billed monthly, per app ^[4]. The AI Agent can create scheduled and API backend workflows but cannot build database triggers or custom events. Branching and loops in the engine are planned, not shipped.

What each operation costs in workload units

Workload is metered per app per calendar month, Development included, and only server work counts. Device-side work is free. Server work is not. Showing elements, setting custom states and reading option sets add nothing, and a workflow costs nothing until its events and actions run. The manual lists these starting costs per operation, and one visible click can trigger several billed operations:

• Page load: 0.15 WU.
• Search: 0.3 WU, plus 0.015 WU per thing and 0.000003 WU per character returned.
• Each thing written or modified: 0.5 WU; each thing deleted: 0.1 WU.
• Aggregate query: 0.2 WU; group-by: 0.3 WU; watching a search: 0.005 WU per call.
• Server-side workflow action: 0.6 WU; scheduling a workflow: 0.1 WU.
• Each database trigger evaluated: 0.05 WU, true or false.
• Outbound API call: 0.1 WU; inbound Data or Workflow API call: 0.01 WU.

Database size does not change what a search costs. How you write it does. Adding :filtered can turn one search into one per row, which the manual illustrates as 1,001 searches for 1,000 products. Plans include 50K WU a month on Free, 175K on Starter, 250K on Growth and 500K on Team. Past that, paid apps pay overages at $0.30 per 1K WU by default, and switching overages off takes the app offline at the limit until you re-enable overages, buy a workload tier or the next billing period starts; our pricing breakdown covers workload tiers.

Two databases, backups and restore windows

Every project starts with two separate databases, Development and Live. Deploying pushes structure to Live (types, fields, option sets and privacy rules), never the data. Copy and restore database moves records between the two in either direction, per data type; copying one type alone can leave links pointing at missing records, so copy all types together. To move a handful of records, export CSV or JSON from one side and import on the other; Data-tab CSV import and export need Bubble's Starter plan or higher.

Bubble backs up both databases continuously, one snapshot per change, and restores a data type to a chosen moment down to the second. That restore undoes everything after the moment, wanted edits included. It cannot pull back one record, leaves types, fields and option sets alone, and restoring Development does not touch Live. How far back you can reach depends on the plan:

Six hours is the figure to remember. A mistaken bulk delete on a Free app, noticed the next morning, is already out of reach, and deleting a database's change history wipes every backup of it for good. Data can leave as CSV (Starter and up), JSON or NDJSON, but the app logic never leaves as code, a lock-in the Bubble review weighs in full. Outside services follow their own rules, covered in the plugins and API Connector guide.

The bottom line

Bubble's database and workflow engine carries real business logic: typed records with relationships, server-enforced privacy rules, and backend jobs that run on schedules, triggers and API calls while nobody has a page open. The discipline it asks for is just as real. Write privacy rules before you add users, keep secrets out of option sets, prefer list scheduling to recursion, and watch per-operation workload while the app is small. Check your plan's restore window before trusting it with live data.