Tenant isolation models

Tenant isolation is a spectrum from sharing everything to sharing nothing. AWS's SaaS guidance names three broad models, pool, bridge and silo, and real systems mix them by layer. The choice is a trade-off between cost per tenant and how strongly each tenant is separated from the others.

The big idea

Sharing lowers cost and raises risk. A pool is the cheapest, and one missing filter can leak data across customers. A silo is the most isolated, and every tenant costs real money to run. Most mature SaaS companies end up tiered. Free and small tenants share a pool, large tenants get dedicated databases or cells, and the enterprise price covers the difference.

Walking through it

The four models side by side:

In the pool model, onboarding a tenant is an INSERT, and migrations run once. The cost is that every query must filter by tenant, and every noisy tenant shares every resource. The schema-per-tenant model runs migrations once per tenant. At thousands of tenants that gets slow and fragile, and Postgres catalogs grow large with tens of thousands of schemas. The database-per-tenant model is expensive. A small managed database instance can cost tens of dollars a month, which can exceed what a small tenant pays.

Why enterprise customers push you up the spectrum

Large customers bring a predictable checklist. Each item has architectural consequences.

• Data residency. Data must stay in a region, so tenants need regional deployments. Logs, backups and analytics must stay in-region too. See multi-region architecture.
• Bring your own key (BYOK). The customer controls the encryption key, usually in their own cloud KMS. You use envelope encryption: data is encrypted with data keys, and the data keys are encrypted with the customer's key. If the customer revokes that key, their data becomes unreadable. This is far easier with a database per tenant. See secrets and encryption.
• SSO and SCIM. Employees log in through the corporate identity provider, and SCIM provisioning deactivates accounts automatically when people leave.
• Audit logs. An immutable, per-tenant record of who did what, kept for a year or more and exportable. Treat it as a product feature with its own storage.

Common mistakes

• Choosing a silo for every tenant. The cost per tenant then exceeds what small tenants pay.
• Choosing a pool without a scoping plan. Pooled data needs enforced isolation. See enforcing tenant scoping.
• Ignoring how tenants move between tiers. Upgrades and residency changes will happen, so design for moving a tenant.

Check yourself

1. Why does the pool model cost the least per tenant?

   Tenants share tables, servers and operations. Onboarding is an INSERT, and migrations run once for everyone.

2. Why can a small tenant not afford a database per tenant?

   A small managed database instance costs tens of dollars a month, which can be more than the tenant pays.

Key takeaways

• Isolation is a spectrum: pool, bridge and silo, with real systems mixing them by layer.
• Pools are cheapest and rely on enforced scoping. Silos are most isolated and cost the most.
• Enterprise requirements such as residency, BYOK, SSO and audit logs push large tenants toward more isolation.

Further learning

Next: enforcing tenant scoping, which covers how a pooled system keeps tenants apart.