If you're building a SaaS product, you're building a multi-tenant system. Every customer that signs up is a tenant. The question isn't whether to handle tenancy — it's how, and getting this wrong is one of the most expensive architectural decisions to reverse after launch.
We've seen the rewrite that comes from a bad tenancy decision. A product that was single-tenant by default, bolted on multi-tenancy later, and spent six months retrofitting isolation boundaries while simultaneously trying to ship product. The rewrite nobody wanted.
Here's how to make the tenancy decision correctly before engineering starts.
The Three Multi-Tenancy Models
Every multi-tenant architecture lives somewhere on a spectrum between fully shared and fully isolated. The three canonical positions:
Model 1: Shared Everything
All tenants share the same database tables. A tenant_id column on every table distinguishes records. Application-level row filtering ensures tenants see only their data.
Pros: Cheapest to operate. Schema changes apply once. No per-tenant provisioning. Easy to query across tenants for analytics.
Cons: Application-level filtering is the only isolation boundary. A bug in the filtering logic exposes one tenant's data to another. Not suitable for regulated industries (HIPAA, GDPR with strong data residency) where logical isolation is insufficient. Performance of noisy neighbors affects all tenants.
When to use: Early-stage SaaS products with homogeneous customers, no regulated data, and a need to move fast. This is the right default for an MVP. Most successful SaaS products start here and migrate later if needed.
Model 2: Shared Infrastructure, Isolated Data
Tenants share application servers, queues, and caches — but each has a dedicated database schema or database.
Schema-per-tenant: Each tenant gets their own schema within a shared Postgres instance. Row filtering is not required — schema boundaries enforce isolation. Schema migrations must be applied to each tenant's schema, which adds deployment complexity as tenant count grows.
Database-per-tenant: Each tenant gets their own Postgres instance. Maximum isolation — a misconfigured query cannot cross tenant boundaries. Highest operational cost: each database instance carries fixed overhead. At 100 tenants, this is manageable. At 10,000 tenants, it becomes expensive and complex to manage without automation.
Pros: Strong data isolation without full infrastructure separation. Works for SOC 2 and GDPR compliance requirements. Noisy neighbor problems are bounded at the database level.
Cons: Schema migrations require automation to roll out to all tenant schemas. Database-per-tenant carries high operational overhead at scale. Cross-tenant analytics queries are more complex.
When to use: B2B SaaS with enterprise customers who have data isolation requirements, compliance needs, or existing data sensitivity. The right choice when your sales process involves security questionnaires.
Model 3: Fully Isolated
Each tenant gets their own application stack, database, and infrastructure — deployed to separate cloud accounts or separate regions if data residency requires it.
Pros: Maximum isolation. Complete tenant customization is possible. Regulatory requirements around data residency (GDPR Article 46, FedRAMP) are most easily satisfied here.
Cons: Highest cost to operate. Deployments are complex (deploy to N environments instead of one). Customer-specific infrastructure means customer-specific incidents. This model requires robust DevOps automation — without it, it's operationally unmanageable.
When to use: Enterprise software sold to government, defense, or regulated industries with strict data residency requirements. Niche: most SaaS products never need this.
The Database Tenancy Decision
The database decision is the most consequential tenancy choice because it's the hardest to change.
Row-level security (RLS) in Postgres provides database-enforced row filtering based on session variables. Unlike application-level filtering, a RLS policy is enforced by the database regardless of what the application sends. An application bug can't bypass it.
Enabling RLS in Postgres:
CREATE TABLE orders (
id uuid PRIMARY KEY,
tenant_id uuid NOT NULL,
-- other columns
);
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
USING (tenant_id = current_setting('app.tenant_id')::uuid);Set the session variable per request:
SET app.tenant_id = '...';RLS gives you database-level enforcement with shared tables — stronger than application filtering, cheaper than schema isolation. For most early-stage SaaS products, RLS on a shared schema is the right call.
Sharding by tenant becomes relevant at scale when a single database instance can't handle the write throughput of the largest tenants. Tenant-based sharding (routing each tenant's writes to a specific shard) keeps queries efficient but adds routing complexity at the application layer.
Authentication and Authorization
Tenancy affects every layer of your auth stack.
Tenant identification on every request. Every API request must be associated with a tenant before any data access occurs. Common patterns: subdomain (acme.yourapp.com → tenant acme), custom domain (mapped to tenant in your routing layer), JWT claim (tenant_id embedded in the session token).
Cross-tenant admin access. Internal operations teams need to access tenant data for support. This requires a separate authentication path — not the tenant-scoped session — with an audit log. Every access to another tenant's data by an internal user should be logged with who, when, and what.
Permission models inside a tenant. Most SaaS products need role-based access control (RBAC) within a tenant: an admin can invite users and change settings; a standard user can only interact with the product. Define the permission model before building — retrofitting RBAC into an application that assumed a flat permission structure is painful.
Organization-level SSO. Enterprise customers will require SAML or OIDC SSO. This needs to be in the architecture from the start if enterprise is in your go-to-market — SSO per tenant means each tenant has their own identity provider configuration. Auth libraries like Clerk or WorkOS handle this out of the box. Rolling your own SAML implementation is a multi-month distraction.
Billing and Subscription Management
Billing in a multi-tenant SaaS has tenant-specific complexity that a simple subscription model doesn't capture:
Usage-based billing. Metered billing (per API call, per active user, per GB of storage) requires tracking usage per tenant and rolling it into invoices. Stripe Meters, Orb, and similar tools handle the metering layer. Your application needs to emit usage events in real time.
Per-seat pricing. If you charge per seat, you need to track active users per tenant accurately. "Active user" needs a definition in your data model — a user who has logged in in the last 30 days? A user who has been invited and accepted? The billing logic depends on the definition, which depends on the data model.
Volume discounts. Enterprise customers negotiate discounts based on seat count or usage. These need to be stored per-tenant and applied at invoice generation time. A single-discount model shared across all tenants doesn't accommodate this.
Invoice and payment history. Tenants need to see their billing history in the product. This means surfacing Stripe data (or equivalent) in your application, scoped to each tenant's subscription.
Background Jobs and Queues
Tenant isolation in background processing is easy to overlook and expensive to fix:
Per-tenant job queues. If all tenants share a single job queue, a burst of expensive jobs from one tenant delays all others. Rate limiting at the queue level — per tenant priority, per tenant concurrency limits — requires queue design from the start.
Noisy neighbor containment. A tenant that triggers a large data export or a long-running report should not slow down every other tenant's jobs. Design your queue to isolate workload spikes per tenant.
Tenant context in jobs. Every background job must know which tenant it's processing for. Set tenant context before any data access in a job handler, and enforce row-level security the same way the API layer does. A background job that skips tenant filtering is a data leak vector.
Multi-Tenancy and Compliance
GDPR (right to erasure): A GDPR deletion request requires deleting all of a tenant's personal data across your system — database records, backups, audit logs, analytics events. If personal data is scattered across shared tables without clear tenant attribution, compliance is difficult. Tenant isolation in your data model makes GDPR requests tractable.
SOC 2 (logical separation): SOC 2 Type II requires demonstrating that customer data is logically separated and that employees can only access customer data through controlled mechanisms with audit logging. The schema-per-tenant or database-per-tenant model satisfies this more cleanly than shared tables with application-level filtering.
HIPAA (PHI isolation): Protected Health Information must be segregated and access-controlled. For healthcare SaaS, database-per-tenant is the most defensible architecture during a HIPAA audit. Shared tables with RLS are acceptable but require more documentation of controls.
Migration Path: From Single-Tenant to Multi-Tenant
The most common situation: a team built a product for one customer and now needs to onboard additional customers. The existing data model has no tenant_id columns.
The migration path:
- ─Add
tenant_idto all user-data tables, nullable initially - ─Set
tenant_idon all existing rows (single backfill) - ─Make
tenant_idnon-nullable - ─Add RLS policies or application-level filtering
- ─Create the first new tenant through the standard provisioning path
- ─Validate isolation before giving new tenants access
The migration is mechanical but requires care with existing data and a deployment that doesn't break the running product. A single-tenant-to-multi-tenant migration is 2–4 weeks of focused engineering, not a rewrite. If you're doing it, do it before you have multiple customers — the presence of real customer data makes the migration riskier.
Building It Right the First Time
The tenancy decisions above — isolation model, database strategy, auth architecture, billing model, queue design — need to be made in week one, not backfilled after launch.
Our web app development practice makes these decisions explicit at the start of every SaaS engagement. The output is a technical architecture document that captures the tenancy model, database design, and auth strategy — decisions that the client owns and that the engineers who come after us can understand.
For products that include AI features within a multi-tenant system (tenant-specific model fine-tuning, per-tenant RAG pipelines, usage metering for AI calls), our AI services team handles the integration with tenant isolation maintained throughout.
And for SaaS products with mobile counterparts — mobile admin apps, field apps, customer-facing iOS/Android — our mobile app development practice builds on the same API layer with tenant context propagated correctly.
Book a 30-min discovery call — we scope your tenancy model, recommend the right isolation strategy for your compliance posture and scale trajectory, and give you a fixed price before work starts.