Multi-tenant SaaS architecture: isolation models compared

Multi-tenant SaaS architecture serves many customers from shared software, and the central design decision is how strongly each tenant is isolated from the others. There are three broad models: silo, where a tenant gets dedicated resources; pool, where tenants share them; and bridge, which mixes the two. Pooled resources cost less per tenant and are simpler to operate, while siloed ones give stronger isolation. Most products end up pooling by default and siloing selectively.

The three isolation models

The names come from the AWS Well-Architected SaaS Lens, and the ideas apply on any cloud.

• Silo. Some or all of a tenant’s resources are dedicated, such as a separate database or a full stack per tenant. AWS stresses that this is still SaaS as long as all tenants are deployed and managed through one shared process.
• Pool. Tenants share resources. This is the classic meaning of multi-tenancy.
• Bridge. Some parts of the system are siloed and others are pooled, often decided service by service.

Microsoft’s guidance on tenancy models describes the same range in different words, from automated single-tenant deployments to fully multitenant ones, with vertically and horizontally partitioned options between. A horizontally partitioned design might share the application tier and give each tenant its own database.

Microsoft puts the cost point plainly: with dedicated infrastructure, 100 tenants probably cost about 100 times what one tenant does. It also notes that a fully shared deployment is riskier to change, because a problem can reach your whole customer base.

Isolation in the data layer

The database is where most teams make this decision first. There are three common patterns.

Database per tenant. Each tenant has its own database or instance. Backup, restore, deletion and data residency are simple per tenant. Schema migrations must run across every database, and connection management gets harder as tenant numbers grow.

Schema per tenant. Tenants share a database server and each has its own schema. This gives a cleaner separation than shared tables, with less overhead than separate databases, though migrations still fan out.

Shared tables with a tenant ID. Every row carries a tenant identifier and every query filters on it. This is the cheapest to run and the easiest to get wrong, because a single missing filter exposes another customer’s data.

For shared tables, do not rely on application code alone. PostgreSQL’s row security policies restrict which rows a query can return or modify, and the database enforces them itself. Three details in the documentation matter in practice:

• When row security is enabled on a table and no policy exists, the default is to deny, so no rows are visible.
• Superusers and roles with the BYPASSRLS attribute always bypass row security.
• Table owners normally bypass it too, unless the table is set to FORCE ROW LEVEL SECURITY.

The lesson is that your application should connect as a role that is neither a superuser nor the table owner. Otherwise the policies you wrote are not being applied.

Isolation beyond the database

A tenant’s data and workload touch more than tables. Check each of these:

• Tenant context. Resolve the tenant once, from the authenticated identity, and carry it through every service call. Never accept a tenant ID from a request parameter without checking it against the session.
• Compute. In a pooled model one tenant’s heavy query or bulk import can slow everyone. Microsoft calls this the noisy neighbor problem. Rate limits, per-tenant quotas and separate queues for heavy jobs keep it contained.
• Caches, queues and search indexes. Include the tenant in every cache key, message and index filter.
• Object storage. Use per-tenant prefixes or buckets, with access policies that match.
• Background jobs and reports. Batch jobs, exports and admin tools often run outside the normal request path and skip its checks.
• Logs and metrics. Tag everything with the tenant, so you can investigate an incident and see what each tenant costs to serve.

How to choose for your multi-tenant SaaS architecture

Answer these questions before you pick a model.

1. What do contracts and regulations require? Some customers will ask for dedicated databases, their own encryption keys or data held in a specific region.
2. How uneven are your tenants? If a few customers produce most of the load, they are candidates for their own resources.
3. How many tenants do you expect? Thousands of small tenants point to a pool. Dozens of large ones can justify silos.
4. Do tenants need customization? Per-tenant schema changes or release schedules are hard in a pool.
5. What can your team operate? A silo model needs strong deployment automation. Without it, every new tenant adds manual work.
6. How do you price? Dedicated resources can be a paid tier that funds their own cost.

A workable default for a new product is a pooled application tier and pooled data with database-enforced isolation, built so that a tenant can be moved to dedicated resources later. That means one tenant routing layer, one onboarding process and no code that assumes every tenant lives in the same place. Microsoft flags the same need: if you allow both models, plan how to migrate a customer between them.

Mistakes to avoid

• Enforcing tenant filters only in application code, with no database policy behind them.
• Connecting to the database as the owner role, which bypasses row security.
• Having no automated test that tries to read one tenant’s data as another.
• Building per-tenant infrastructure by hand, so tenant number fifty takes as long as tenant number five.
• Having no per-tenant cost or usage data, which makes pricing and capacity decisions guesswork. Tagging spend by tenant is a core practice in FinOps for AI and cloud costs.
• Leaving isolation undocumented. Enterprise buyers and auditors will ask how it works, as covered in SOC 2 readiness for SaaS.

How YLinkTech helps

We work with SaaS and technology companies at the points where tenancy decisions get expensive: the first enterprise customer, a scaling problem, or a move upmarket. Our Digital Product Engineering practice designs and builds multi-tenant platforms through its custom software development work, including tenant routing, database isolation, onboarding automation and migration of tenants between models. If you are reviewing your architecture, contact us and we will look at it with you.

Frequently asked questions

Sources

• AWS Well-Architected SaaS Lens: Silo, Pool, and Bridge Models
• AWS Well-Architected SaaS Lens: Tenant Isolation
• Microsoft Azure Architecture Center: Tenancy models for a multitenant solution
• PostgreSQL Documentation: Row Security Policies

This article is general information, not professional advice. See our Disclaimer.