Why Multi-Tenancy Is the Foundation of SaaS Economics
Multi-tenancy — serving multiple customers from a shared infrastructure — is what makes SaaS economically viable. According to Bessemer Venture Partners' State of the Cloud 2025, SaaS companies that achieve true multi-tenancy operate at 65-80% gross margins, compared to 40-55% for single-tenant hosted solutions. The difference is infrastructure efficiency: shared resources, shared operations, and shared deployments.
But multi-tenancy introduces genuine architectural complexity. Tenant isolation, noisy neighbour problems, per-tenant customisation, and data sovereignty requirements all need to be solved at the architecture level. Getting this wrong is expensive — we have seen SaaS companies spend 12-18 months refactoring single-tenant architectures that could not scale past 50 customers.
The Three Isolation Models
Every multi-tenant architecture falls somewhere on a spectrum between full isolation and full sharing. AWS describes three primary models:
1. Silo Model (Full Isolation)
Each tenant gets dedicated infrastructure: separate databases, separate compute, and sometimes separate accounts or VPCs.
- Pros — Strongest isolation. No noisy neighbour risk. Simplest compliance story for regulated industries. Per-tenant performance tuning.
- Cons — Highest cost per tenant. Operational complexity scales linearly with tenant count. Deployment becomes N-times harder.
- When to use — Enterprise customers with strict compliance requirements (financial services, government, healthcare). Customers willing to pay a premium for dedicated resources.
2. Pool Model (Full Sharing)
All tenants share the same infrastructure: same databases, same compute, same everything. Tenant separation is enforced at the application layer.
- Pros — Lowest cost per tenant. Simplest operations. Single deployment target. Maximum resource efficiency.
- Cons — Noisy neighbour risk. A single tenant's query can degrade performance for everyone. Tenant isolation depends entirely on application correctness — one bug can leak data between tenants.
- When to use — High-volume, low-ARPU products (developer tools, SMB SaaS). Tenants with similar usage patterns and no regulatory isolation requirements.
3. Bridge Model (Hybrid)
Some components are shared, others are isolated. Typically: shared compute with isolated databases, or shared databases with isolated schemas.
- Pros — Balances cost and isolation. Can tier isolation by customer plan (shared for free/basic, isolated for enterprise).
- Cons — More complex than either pure model. Requires careful component-level isolation decisions.
- When to use — Most SaaS products. The bridge model lets you offer enterprise-grade isolation to customers who need it while maintaining efficiency for the majority.
Database Multi-Tenancy Strategies
The database is where multi-tenancy decisions have the most lasting impact. There are three primary strategies, each with different trade-offs:
Strategy 1: Shared Database, Shared Schema (Tenant ID Column)
All tenants share tables, with a tenant_id column on every table that holds tenant-specific data.
-- Every query must include tenant_id
SELECT * FROM invoices WHERE tenant_id = 'acme-corp' AND status = 'pending';
-- Row-Level Security (PostgreSQL)
CREATE POLICY tenant_isolation ON invoices
USING (tenant_id = current_setting('app.current_tenant'));- Pros — Most resource-efficient. Single connection pool. Simplest backup and migration strategy.
- Cons — A missing
WHERE tenant_id = ?clause leaks data. Index design must account for tenant_id prefix. Large tenants can degrade shared table performance. - Mitigation — Use PostgreSQL Row-Level Security (RLS) to enforce isolation at the database level. Set the tenant context at connection time and let the database enforce it. This is our recommended approach for most SaaS applications.
Strategy 2: Shared Database, Separate Schemas
Each tenant gets their own database schema within a shared database instance.
-- Tenant-specific schema
SET search_path TO 'tenant_acme';
SELECT * FROM invoices WHERE status = 'pending';- Pros — Stronger isolation than shared schema. No risk of missing tenant_id filters. Per-tenant schema migrations are possible.
- Cons — Schema count limits (PostgreSQL handles thousands, but connection pools get complex). Migrations must be applied N times. Reporting across tenants requires cross-schema queries.
Strategy 3: Separate Databases
Each tenant gets a dedicated database instance.
- Pros — Strongest isolation. Independent scaling, backup, and restore per tenant. Easiest compliance story.
- Cons — Highest cost. Connection management complexity grows with tenant count. Operational overhead of managing hundreds of database instances.
Tenant-Aware Authentication and Authorisation
Authentication in a multi-tenant system must resolve two questions: who is this user, and which tenant do they belong to?
Recommended Architecture
- Tenant resolution — Identify the tenant from the request. Common strategies: subdomain (
acme.yourapp.com), path prefix (/api/tenants/acme/), or JWT claim. Subdomains are the cleanest approach for user-facing apps. - JWT with tenant claims — Include
tenant_idandtenant_rolein the JWT. Validate these claims at every API endpoint. Never trust client-supplied tenant identifiers outside of the JWT. - Middleware enforcement — Implement a middleware layer that extracts the tenant from the JWT, sets the database context (RLS current_setting or schema search path), and rejects requests with missing or invalid tenant claims.
Handling the Noisy Neighbour Problem
In a shared-resource architecture, one tenant's heavy usage can degrade performance for all others. This is the noisy neighbour problem, and it must be solved architecturally:
- Rate limiting per tenant — Implement per-tenant rate limits at the API gateway level. Use token bucket algorithms that allow bursts while capping sustained throughput.
- Database connection pooling per tenant — Use PgBouncer or similar connection poolers with per-tenant connection limits. Prevent one tenant from consuming the entire connection pool.
- Compute isolation for heavy workloads — Route computationally expensive operations (report generation, data exports) to separate worker pools with per-tenant quotas.
- Queue-based processing — Offload long-running operations to message queues with per-tenant fairness scheduling. This prevents a tenant with 100,000 queued jobs from starving other tenants' jobs.
Data Sovereignty and EU Considerations
For European SaaS companies, data sovereignty adds a dimension to multi-tenancy design. GDPR requires that personal data of EU residents can be processed and stored in compliance with EU regulations. Some customers (particularly government and financial services) require data residency — data must physically reside within a specific jurisdiction.
Architectural solutions include:
- Regional database sharding — Route tenants to database instances in their required region (eu-west-1 for EU, us-east-1 for US).
- Tenant metadata service — Maintain a lightweight global service that maps tenants to their designated region, then route all data operations accordingly.
- Cell-based architecture — Each "cell" is a fully self-contained deployment in a specific region. Tenants are assigned to cells. This is the approach used by AWS itself for many of its services.
Start Building
Multi-tenancy decisions made early in a SaaS product's life shape its economics, scalability, and compliance posture for years. Refactoring a single-tenant system into a multi-tenant one is typically a 6-12 month effort that requires near-zero downtime migration — far more expensive than designing it correctly from the start.
If you are building a new SaaS product or need to evolve your existing architecture, our full-stack development teams have built multi-tenant systems serving thousands of tenants across Europe. Get in touch for an architecture review.
