Multi-Tenant SaaS Infrastructure: Isolation Models and Their Costs

The tenant isolation model is the architectural decision with the longest shadow in a SaaS platform. It determines your cost per customer, your blast radius when something fails, what you can promise in a security questionnaire, and how hard it is to serve a customer who insists their data sits in a specific country.

Choosing it deliberately early is far cheaper than discovering it late.

The three models

Shared everything. One application, one database, one schema. Every table carries a tenant identifier and every query filters on it.

Schema per tenant. One database, one schema per tenant. Shared infrastructure, separated data namespaces.

Database or stack per tenant. Each tenant gets its own database, and sometimes its own application instance entirely.

The risk in shared everything

It is the cheapest model and the one with the sharpest failure mode: a single missing WHERE tenant_id = ? exposes one customer's data to another. That is a reportable data breach, not a bug.

If you choose this model, the defence has to be structural rather than disciplinary:

• Enforce isolation in the data layer, not in application code. PostgreSQL row-level security ties the filter to the database session so a forgotten clause fails closed.
• Make the tenant context implicit — set it once per request at the connection level, never passed as a parameter each query.
• Test for cross-tenant leakage explicitly in your test suite, as a first-class test category.
• Log every cross-tenant access attempt and alarm on it.

Relying on every developer remembering every time is not a control.

Noisy neighbours

In shared models one tenant's behaviour affects everyone. A customer importing ten million rows, or running an unbounded report, degrades the platform for others.

Mitigations, in order of effectiveness:

1. Rate limit per tenant, not globally.
2. Queue heavy operations rather than running them synchronously.
3. Separate read replicas for reporting so analytical queries never touch the transactional path.
4. Per-tenant resource quotas on storage, API calls and background job concurrency.
5. Move the largest tenants to dedicated capacity — a hybrid model that works well in practice.

That last point is worth emphasising. Most mature SaaS platforms end up hybrid: shared infrastructure for the long tail, dedicated stacks for the handful of large or regulated customers who require it and pay for it.

Compliance and residency

Enterprise customers ask two questions that the tenancy model answers for you:

• "Is our data logically or physically separated?" Shared models answer "logically", which is acceptable to many buyers and unacceptable to some.
• "Can our data stay in our jurisdiction?" Only a stack-per-tenant model, or a region-partitioned deployment, can answer yes.

If enterprise or public-sector customers are in your plan, this shapes the architecture before it shapes the sales conversation. Platforms serving regulated buyers frequently end up on infrastructure chosen for its compliance posture — an Azure account for organisations already inside a Microsoft compliance envelope, or an IBM Cloud account where encryption controls are contractually specified.

Operational consequences

• Migrations are trivial in shared models and a fleet operation in per-tenant models. Automate from day one; a hundred schemas migrated by hand is not a process.
• Backups and restore are the reverse: restoring one tenant from a shared database means extracting rows; from a per-tenant database it is a single restore.
• Onboarding is instant in shared models and a provisioning workflow in per-tenant ones.
• Observability must be tenant-aware in every model. Metrics and logs without a tenant dimension make per-customer problems invisible.

Choosing

Start shared if tenants are numerous, small and homogeneous, and if no customer will demand physical separation. Add row-level security from the beginning rather than retrofitting it.

Start per-tenant if tenants are few, large, and likely to require separation, residency or independent restore.

Plan for hybrid either way, because successful platforms acquire customers who need more isolation than the default provides.

Frequently asked questions

Can I migrate from shared to per-tenant later? Yes, and it is a substantial project. Designing the data access layer so the tenant context is already explicit makes it much easier.

Does row-level security cost performance? There is overhead, usually modest, and it is generally a good trade for structural safety. Measure on your own workload.

How do I handle per-tenant custom fields? A JSON column with an indexed subset is usually better than per-tenant schema changes, which multiply migration complexity.

Should each tenant get its own subdomain? It simplifies tenant resolution and looks better to customers. It also means wildcard certificates and DNS automation, which are minor once set up.

The networking guide covers the isolation layer below the application.