Multi-Tenant Architecture in SaaS: Three Approaches and Selection Criteria

In SaaS products, a single application serves many customers. Each customer is called a “tenant,” and only that customer should be able to see its own data. How tenants' data is separated is an architectural decision that affects the product's cost, security and operational burden for years.

Three basic approaches

1. Shared database, shared schema

All tenants' data sits in the same tables; each row carries a field showing which tenant it belongs to. Every query is filtered by this field. It is the approach that is simplest to set up and operate and the most efficient in its use of resources.

The risk is that a single query in which the filter is forgotten can expose another tenant's data. This risk is reduced by enforcing the filter at the database level instead of leaving it to the application code; for example, PostgreSQL's row-level security feature is used for this purpose.

2. Shared database, separate schema per tenant

Tenants share the same database server, but each one's tables sit in a separate schema. Isolation is stronger, and restoring a single tenant's data from a backup becomes easier. On the other hand, as the number of tenants grows, applying schema changes to all the schemas becomes harder.

3. Separate database per tenant

Each tenant has its own database. Isolation is at its highest level; one tenant's heavy usage does not affect the others, and requests such as keeping the data in a specific region can be met. The price is a higher infrastructure cost and the operational burden that comes with managing a large number of databases.

Comparison

Criterion	Shared schema	Separate schema	Separate database
Data isolation	Logical	Stronger	Strongest
Cost per tenant	Lowest	Medium	Highest
Schema changes	In one go	For each schema	For each database
Tenant-specific backup and restore	Difficult	Easy	Easiest
Many small tenants	Very suitable	Limited	Not suitable
A few large enterprise tenants	May be sufficient	Suitable	Very suitable

What determines the choice?

• Customer profile: Will you serve thousands of small businesses or a small number of large organizations?
• Contractual and regulatory requirements: Do customers require their data to be kept physically separate?
• Level of customization: Will tenants only change settings, or will they want fields and workflows specific to them?
• Team capacity: Do you have the operational capacity to monitor and update a large number of databases?

The hybrid model

The approaches can also be used together. A common arrangement is to keep customers on standard plans in a shared schema while offering enterprise customers a separate database. For this to be possible, the tenant information must be carried through every layer of the application from the start.

What needs to be considered beyond the database

• Identity and permissions: It must be known with certainty which tenant each session belongs to; if users can be members of more than one tenant, switching must be set up securely.
• Resource sharing: One tenant's heavy usage must not slow the others down. Rate limits and per-tenant quotas for background jobs are used for this purpose.
• Files and cache: Isolation must be ensured not only in the database but also in file storage, the cache and the search index.
• Monitoring: Error and performance logs must include the tenant information; otherwise the question “which customer was affected?” goes unanswered.

For most SaaS products, a shared schema is the right starting point; what matters is that it is built in a way that will not prevent a move to a separate database in the future.

To plan your product's architecture together, you can take a look at our SaaS product development service.