If you're building a B2B SaaS where many customers share one app, decide three things before your first migration: how tenants share storage, where the database enforces isolation, and how a login maps to exactly one tenant. Get those right and most backend problems become manageable. Get them wrong and you ship a data leak.
Multi-tenant SaaS architecture is the set of decisions that let one running application serve many customers (tenants) while keeping each tenant's data private. Your first action today: write down which of your tables hold tenant data, and check whether the database itself would stop a query that forgets the tenant filter.
This is the hub for architecture on this site. Below are the model trade-offs, the isolation rules I use, and how they connect to auth and multi-region. Each deeper post is linked in context, so you can jump to the decision you're stuck on.
What are the main multi-tenant database design options?
There are three common tenancy models: shared tables with a tenant column, a schema per tenant, or a database per tenant, and most B2B SaaS starts with the shared-table model because it has the least operational weight.
AWS's SaaS guidance describes the same spectrum as silo (dedicated resources per tenant), pool (shared resources) and bridge (a mix), and it notes that pooled resources need fine-grained policies to control access, while dedicated stacks can rely on coarser network-level ones (AWS SaaS architecture fundamentals, tenant isolation; AWS marks this whitepaper as kept for historical reference, so I use it for the concepts only).
| Model | Isolation strength | Operational cost | Typical fit |
|---|---|---|---|
Shared tables + tenant_id | Logical; needs database-enforced rules | Lowest: one schema, one migration | Most early and mid-stage B2B SaaS |
| Schema per tenant | Stronger logical separation | Migrations fan out across N schemas | Mid-size tenants, stricter separation |
| Database per tenant | Physical | Highest: fleet migrations, connection limits | Contractual separation, noisy-neighbor tenants |
The model sets the blast radius of a mistake. In a shared-table design, one query without the tenant filter exposes every tenant. In a database-per-tenant design, a leak stays inside one tenant, but you now run many databases and many migrations. My recommendation for a founder shipping an MVP is shared tables plus database-enforced rules, moving off only for a concrete, named reason: a compliance clause, a measured noisy-neighbor problem, or a residency requirement. The full decision tree is in database-per-tenant vs shared schema for SaaS, and the sequencing of these choices in a first build is in the SaaS MVP development guide. Pick the model before you write the first migration; adding tenant_id to a live schema later is painful.
How do you isolate tenant data at the database layer?
Isolation should live in the database itself, so a query that forgets the tenant filter returns nothing instead of another customer's rows. Application code alone can't carry that guarantee.
Application code gets written in a hurry and refactored constantly. Sooner or later a report, an admin tool or an AI-generated query omits the WHERE tenant_id = ? clause. AWS makes the same point from the other side: authentication and authorization alone don't achieve isolation, because an authenticated, authorized user can still reach another tenant's resources unless something blocks it (AWS).
The scale of the underlying problem is documented. In the OWASP Top 10:2025, Broken Access Control ranks first, and OWASP reports that 100% of the applications tested had some form of it, with an average incidence rate of 3.74% across the mapped weaknesses. Cross-tenant reads are that category applied to a SaaS product.
Postgres: Row-Level Security
Enable RLS on a table, write a policy that compares tenant_id to a value set from the authenticated request, and every query is scoped automatically. The PostgreSQL documentation states that with RLS enabled and no policy defined, a default-deny applies: no rows are visible or modifiable. Two caveats from the same page matter in practice: table owners and roles with BYPASSRLS skip policies unless you run ALTER TABLE ... FORCE ROW LEVEL SECURITY, and foreign-key integrity checks always bypass RLS.
On Supabase, the RLS guide adds that tables created in the dashboard don't have RLS on by default, that the secret (service-role) key has bypassrls, and that a policy relying on user_metadata is unsafe because signed-in users can modify it; use raw_app_meta_data instead (Supabase RLS guide). The full policy walkthrough is in multi-tenant SaaS with Supabase RLS.
Firestore: security rules
Firestore has no SQL WHERE to forget; instead each document carries its tenant, and rules compare it to a claim on the auth token. The Firebase custom claims documentation says the payload must not exceed 1000 bytes and should hold access-control data only, and that claims reach clients on sign-in, on token refresh, or when the client calls getIdToken(true). The Firestore rules reference adds a detail that trips people up: rules aren't filters, so a query that could return documents the user can't read fails as a whole, and your where() clauses must match your rule conditions.
Callidus, the UK aesthetic-clinic SaaS I built on React and Firebase, stores everything under tenants/{tenantId}/… in Firestore, with tenantId and role carried as JWT claims, per its case study. The rule layer, not the React code, is the isolation boundary. For the production rule patterns, see Firestore rules for a multi-tenant clinic SaaS, and for the head-to-head comparison, Firestore rules vs Postgres RLS.
Test it adversarially
Log in as tenant A, take a record ID belonging to tenant B, and request it directly. Anything other than "denied" or an empty result means your isolation is theater. This is the class of bug AI coding assistants introduce easily, which is why I review every access-control change by hand; the wider mindset is in the SaaS security and compliance pillar.
How does authentication map a user to a tenant?
Authentication proves who the user is, while tenancy decides whose data they may touch, so the tenant must come from the verified session or token and never from a parameter the client controls.
If your API trusts a tenantId in the request body or URL, any signed-in user can change it and walk through your checks. Put the tenant, or the user's tenant memberships, into a claim at login, and derive every query's scope from that claim. On Supabase that is a claim feeding the RLS policy; on Firebase it is a custom claim that the security rules read.
Users who belong to several tenants, such as an agency managing client workspaces, need an active-tenant concept. Model memberships as a join table (user_id, tenant_id, role), let the user switch explicitly, and re-issue or re-scope the token on the server instead of trusting a header. Role design on top of that is covered in designing RBAC for multi-tenant SaaS, and creating the tenant and its first admin is in tenant provisioning and onboarding architecture.
The login method itself (magic link, OAuth, password) is a separate decision. I lean toward magic link or OAuth for most B2B products because there are fewer credentials to leak, but it depends on your buyers; the trade-offs are in SaaS authentication: magic link vs OAuth. Where auth meets billing, such as mapping a tenant to a Stripe customer, you're at the edge of the SaaS billing and payments pillar.
When is multi-region deployment worth the complexity?
Multi-region is worth it only for a legal data-residency requirement or for measured latency problems you can't fix with cheaper tools. Most B2B SaaS should start in one region.
Residency is a compliance question, not a performance one, and it interacts with your tenancy model: database-per-tenant or schema-per-tenant makes per-region placement cleaner than one global shared table. Latency counts only when real users on another continent are measurably hurt and you've already tried edge caching and read replicas. Multi-region multiplies replication and consistency work, failover, per-region secrets and migration coordination. Ship in one region, instrument latency, and watch your sales pipeline for residency clauses before designing expansion. The decision criteria are in multi-region SaaS deployment: when and how, and the surrounding jobs, webhooks and admin tooling are in the SaaS backend infrastructure pillar.
How do the case studies on this site use these ideas?
Two of my builds are multi-tenant in the sense used here. Callidus is the clinic SaaS above. BookBed is a Flutter, Firebase and Stripe booking product whose pricing is described in its case study as up to twenty units per tenant; its subscription billing is wired but not yet activated for paid traffic, and it also does bidirectional iCal sync. Pizzeria Bestek, a React and Supabase build, is a single-restaurant project, so it isn't a multi-tenant example, although its case study lists Row-Level Security on all tables. For the mobile side of tenancy, see multi-tenant mobile SaaS patterns in Flutter.
If you're weighing in-house, agency or solo delivery for a build like this, the trade-offs are in hiring SaaS developers, and my approach is described in AI-augmented development.
Which of your tables would still leak if a developer forgot the tenant filter tomorrow? Answer that for each one before you pick a model, and send me the list if you want a second pair of eyes.