Multi-tenancy Patterns

Table of Contents

🟠 P1 — directly relevant to Stripe (multi-tenant SaaS platform)

Problem #

Your platform serves many customers (tenants). Each tenant’s data must be isolated, performance must be fair, and one tenant’s load must not degrade others’ experience.

Isolation Strategies #

Strategy	Data isolation	Performance isolation	Operational cost
Shared everything	Tenant ID column on every table	Noisy neighbour risk	Lowest
Schema-per-tenant	Separate schema, shared DB	Better isolation	Medium
Database-per-tenant	Separate database instance	Strong isolation	Highest
Hybrid	Shared default, dedicated for large tenants	Balanced	Medium-High

Noisy Neighbour Problem #

One tenant running expensive queries or high write volume degrades performance for all tenants on the same infrastructure.

Mitigations:

Per-tenant rate limiting: Cap requests/resources per tenant (see also: Rate Limiting)
Resource quotas: CPU, memory, I/O limits per tenant
Query governors: Kill queries that exceed time/resource thresholds
Tenant-aware routing: Route large tenants to dedicated resources

Instinct #

Start with shared-everything + tenant ID + per-tenant rate limiting. It’s the simplest to operate. Only move to schema-per-tenant or database-per-tenant when you have tenants whose isolation requirements (regulatory, SLA, or scale) justify the operational cost. Stripe’s model: shared infrastructure with sophisticated per-merchant rate limiting and resource isolation.

References #

AWS: SaaS Tenant Isolation Strategies
Designing Your SaaS Database for Scale with Postgres — Citus
Stripe Connect Documentation — Stripe’s multi-tenant model