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.

Isolation Models Within Multi-Tenancy

Multi-tenant systems implement varying degrees of isolation between tenants depending on their security and compliance requirements: some share a single database schema with a tenant identifier column filtering every query (simplest and cheapest, but requiring careful, consistent enforcement to prevent one tenant’s queries from ever accidentally accessing another’s data), others give each tenant a separate database schema within shared infrastructure (stronger isolation, more operational overhead), and the strictest approach provisions entirely separate database instances per tenant while still sharing application infrastructure. The right isolation level is a genuine architectural decision balancing cost efficiency against the strength of isolation guarantees a given customer base or regulatory environment requires, and many SaaS platforms actually offer multiple tiers, with higher-paying enterprise customers sometimes receiving stronger isolation than what standard tenants get by default.

Noisy-neighbor effects are the most common operational symptom of imperfect tenant isolation in practice: one tenant’s unusually heavy usage degrading performance for others sharing the same underlying infrastructure, which is why resource quotas and rate limiting per tenant are just as important a part of a multi-tenant architecture as the data isolation model itself.