Designing a Multi-Tenant SaaS Architecture

Multi-tenancy allows multiple customers (tenants) to share the same infrastructure while keeping their data isolated.

Tenancy Models

Silo Model (Dedicated)

Tenant A → Own DB + Own App Servers
Tenant B → Own DB + Own App Servers

Pros: Maximum isolation, customization Cons: Expensive, hard to manage Use: Enterprise customers, regulated industries

Pool Model (Shared)

All Tenants → Shared App Servers → Shared DB
              (tenant_id in every table)

Pros: Cost-efficient, easy to scale Cons: Risk of data leakage, noisy neighbor Use: Startup, SMB customers

Bridge Model (Hybrid)

Small tenants  → Shared pool
Large tenants  → Dedicated siloes

Use: Most production SaaS

Data Isolation

Row-Level Security (PostgreSQL)

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.tenant_id')::UUID);

Schema-per-Tenant

-- Each tenant gets own schema
CREATE SCHEMA tenant_abc;
CREATE TABLE tenant_abc.orders (...);

Tenant Context

Request → Extract tenant from JWT / subdomain / header
        → Set tenant_id in request context
        → All DB queries automatically scoped

Noisy Neighbor Problem

One tenant consuming excessive resources affects others.

Solutions:

• Resource quotas per tenant (CPU, API rate limits)
• Separate queues per tier (enterprise, standard)
• Auto-scale per tenant group

Onboarding Pipeline

Sign up → Provision tenant (create schema/DB)
       → Seed default data
       → Assign to server pool
       → Send welcome email

Conclusion

Bridge model (shared for small, dedicated for large tenants) with row-level security is the industry-standard approach for scalable SaaS.