The Bubble Multi-Tenancy Architecture We Use on Every SaaS
Multi-tenancy is not a feature — it is an architectural commitment that must be designed from day one. Our exact four-layer pattern, privacy rule templates for every data type category, and the three-test isolation protocol we run before every deployment.
Multi-Tenancy Is Not a Feature — It Is an Architectural Commitment
Multi-tenancy is the property of a SaaS application whereby a single instance of the application serves multiple customers, with each customer’s data completely isolated from every other customer’s data. In Bubble, achieving this correctly requires a specific and deliberate architectural approach. It cannot be added after the fact without significant refactoring. It must be designed from day one. This is the exact multi-tenancy architecture we implement on every SaaS project.
The Four-Layer Architecture
Workspace
: name, plan, subscription_status, owner, stripe_customer_id
member_count, record_count, created_date, settings
// LAYER 2: Membership Data Type (who belongs to what)
Membership
: user (User), workspace (Workspace), role (option set)
status (Active/Invited/Removed), invited_by, joined_at
// LAYER 3: All app data types carry workspace reference
Project
: workspace (Workspace), name, status, created_by, …
Task
: workspace (Workspace), project (Project), assignee, …
// Note: workspace on Task is redundant with Task->Project->Workspace
// But direct workspace field enables faster, simpler search constraints
// LAYER 4: Current workspace on User (session context)
User
: current_workspace (Workspace), … other profile fields
// Updated on workspace switch, login, and workspace creation
How We Write Privacy Rules for Every App Data Type
Condition
: Search for Memberships [user=Current User, workspace=This Record’s workspace, status=Active]:count > 0
Permissions
: Find ✓ View all fields ✓
// Stricter rule for admin-only types (e.g. billing, settings)
Condition
: Search for Memberships [user=Current User, workspace=This Record’s workspace, role=Admin_or_Owner, status=Active]:count > 0
Permissions
: Find ✓ View all fields ✓ Edit ✓
// Creator-only type (e.g. personal notes, drafts)
Condition
: This Record’s created_by = Current User
Permissions
: Find ✓ View ✓ Edit ✓ Delete ✓
// Append-only audit log
Condition
: Search for Memberships [user=Current User, workspace=This Record’s workspace]:count > 0
Permissions
: Find ✓ View all fields ✓ Create ✓ Edit ✗ Delete ✗
How We Verify Tenant Isolation Before Every Deployment
Architecture without testing is speculation. Before every production deployment, we run the two-browser tenant isolation test. This is not optional and cannot be skipped regardless of timeline pressure.
Setup
: Browser A logged into Workspace A with 10 test records across all data types
Browser B logged into Workspace B (different user, different workspace)
Test 1: Page navigation
Navigate every page in Browser B
PASS: zero records from Workspace A appear anywhere
FAIL: any Workspace A data visible in Browser B
Test 2: Direct URL access
Copy URL of a Workspace A record detail page from Browser A
Paste into Browser B and navigate
PASS: page shows empty/error state
FAIL: Workspace A record data loads for Workspace B user
Test 3: API access
Using Browser B user’s API token, call /api/1.1/obj/[type]
PASS: only Workspace B records returned
FAIL: any Workspace A record appears in response
Work With a Bubble Architect
Most developers build Bubble apps. We architect them. Data models designed for scale, multi-tenant security built from day one, Stripe billing that never fails, and workflows engineered for performance. This is what a Bubble Architect delivers.
