Multi-Tenancy

What is multi-tenancy?

In multi-tenant SaaS, one deployed application serves many customers (tenants). Each tenant’s data is logically separated — Tenant A cannot see Tenant B’s records — while sharing underlying infrastructure.

Tenancy models

Model	Description
Shared app + shared DB	Row-level tenant ID column (most common)
Shared app + DB per tenant	Stronger isolation, higher ops cost
Instance per tenant	Maximum isolation (enterprise / regulated)

Why SaaS vendors use it

• Economies of scale — one deploy benefits all customers
• Faster updates — ship features once, available everywhere
• Lower marginal cost — adding tenant 1001 is cheaper than tenant 1

Design considerations

• Tenant context — every query scoped by tenant ID
• Noisy neighbor — rate limits and quotas per tenant
• Customization — feature flags, branding, config without separate codebases
• Compliance — some industries require dedicated infrastructure

Multi-tenant vs single-tenant

Single-tenant dedicates infrastructure per customer. Higher cost, simpler blast-radius isolation. Enterprise deals sometimes mandate single-tenant or VPC peering models.

What people get wrong

• Enforcing tenancy in application code only. One forgotten WHERE tenant_id = is a data breach. Push isolation down: row-level security in the database, scoped credentials per request.
• Ignoring the noisy neighbor until it hurts. One tenant’s batch import degrading everyone else’s latency is the classic multi-tenant incident; per-tenant quotas and rate limits are day-one requirements.
• Promising enterprise isolation you haven’t built. “Dedicated instance” sold before the architecture supports it becomes a hand-run snowflake per customer — the worst of both models.