SaaS Data Model: The Foundation Every SaaS Product Is Built On
The data model is the most consequential design decision in any SaaS product. The four-type SaaS data model (User, Workspace, Membership, Plan), the critical workspace field rule, and the privacy rules that enforce multi-tenant isolation at the database level.
The Technical Foundation Every SaaS Product Is Built On
A SaaS data model is the structured design of how a multi-tenant SaaS product stores, relates, and protects its data. The correct SaaS data model includes four core types: User (identity), Workspace (tenant boundary), Membership (user-to-workspace relationship with role), and Plan (subscription tier). Every application-specific data type is built on this foundation with a workspace field that scopes each record to its owning organisation.
The data model is the most consequential design decision in any SaaS product. Every feature, every workflow, every security rule, and every billing integration is built on top of the data model. A correctly designed data model enables all future features. An incorrectly designed one makes every future feature more expensive — and may create security vulnerabilities that persist for months before being discovered.
The Four-Type Foundation Every SaaS Needs
| Data Type | Purpose | Key Fields | Critical Rule |
|---|---|---|---|
| User | Authentication and identity for every person who accesses the system | email (unique), name, current_workspace (→ Workspace) | Bubble creates this automatically; add current_workspace field |
| Workspace | The tenant boundary; every customer organisation has one Workspace record | name, owner (→ User), plan (→ Plan), subscription_status (option set), stripe_customer_id, stripe_sub_id | Privacy rule: members can read; owner can edit billing fields |
| Membership | Links a User to a Workspace with a specific role; enables role-based access | user (→ User), workspace (→ Workspace), role (option set: Owner/Admin/Member/Viewer), status (Active/Invited) | Role stored here, NOT on User; enables different roles per workspace |
| Plan | Defines each subscription tier and its limits | name, stripe_price_monthly, stripe_price_annual, seat_limit, record_limit, trial_days | Separate from Workspace; read by Workspace via the plan field |
How to Enforce Tenant Isolation at the Database Level
Privacy rules in Bubble.io are row-level access control rules that run server-side before any query returns data. They are the mechanism that makes multi-tenant isolation work. Without them, any authenticated user can query any record of any type via the Bubble Data API.
The standard privacy rule for any application data type: Find and View allowed when Search for Memberships [user = Current User, workspace = This Record’s workspace, status = Active]:count > 0. This rule ensures that a record is only returned to users who are active members of the workspace that owns it.
Admin-only data types (billing records, audit logs, workspace settings) use an additional role condition: role is in [Owner, Admin] in the membership search. This restricts visibility to users with elevated permissions while maintaining tenant isolation.
Free SaaS Tech Audit — 30 Minutes, No Cost
Athar Ahmad personally reviews your SaaS product: security vulnerabilities, billing gaps, performance anti-patterns — identified and ranked before they cost you customers, deals, or investor confidence.
- Multi-tenant security and privacy rule assessment
- Stripe billing architecture review
- Performance bottleneck identification
- Written remediation roadmap within 24 hours
Q: What is a multi-tenant data model?
A multi-tenant data model is a database design where multiple customers (tenants) share the same database tables, with each customer’s records identified by a tenant identifier (workspace field) and protected by row-level access control (privacy rules). It is the standard data model for SaaS products.
Q: Why should SaaS roles be on the Membership record, not the User record?
If roles are stored on the User record, a user has one role across all workspaces. This makes it impossible for a user to be an Admin in one organisation and a Member in another — a common requirement in B2B SaaS where users belong to multiple workspaces.
Q: How do I design a SaaS data model?
Design on paper before opening any development tool. List every noun in the system (every thing the application stores information about). For each noun: list every field, its type, and its relationships to other nouns. Add a workspace field to every application data type. Design privacy rules for every type before creating any records.
Build or Fix Your SaaS. Two Paths. Both Lead to Better Outcomes.
Free Tech Audit for SaaS products that exist and need assessment. Discovery Sprint to scope and price new SaaS ideas correctly before a single line is built.
