Every SaaS product has to answer one structural question early: when hundreds of customers use the same application, where does each customer's data live, and what stops one customer from seeing or slowing down another? That decision is called the tenancy model. It shapes your hosting bill, how quickly you can onboard customers, which enterprise deals you can sign, and how painful a data recovery will be.

This guide explains multi-tenancy in plain terms and compares the four main isolation models, using published architecture guidance from AWS, Microsoft Azure and Google Cloud, linked throughout.

Quick answer

• Multi-tenancy means one running application serves many customers (tenants), with each tenant's data kept separate.
• Shared tables with a tenant ID are the cheapest and simplest to run, and suit most early-stage and self-serve products. Isolation depends on your code and database policies.
• Schema per tenant gives a clearer logical boundary inside one database, but adds operational work and does not solve performance interference.
• Database per tenant gives strong data isolation and simple per-tenant restore, at higher cost and with a real need for automation.
• Fully isolated deployments give each tenant its own stack, and are usually reserved for customers whose compliance, residency or performance demands justify the price.
• Most mature products end up hybrid: shared by default, dedicated for a few large customers. Plan for that by putting a tenant ID everywhere and keeping a central record of where each tenant lives.

What multi-tenancy means in plain terms

A tenant is a customer of your SaaS product. In a business-to-business product a tenant is usually a company with many users. Microsoft's guidance points out that the mapping is not always one-to-one: a single customer may need several tenants, for example to keep divisions, regions, or test and production environments apart (Azure Architecture Center: tenancy models).

AWS uses three terms for this. In a pool model tenants share resources. In a silo model tenants get dedicated resources. A bridge model mixes the two (AWS Well-Architected SaaS Lens). AWS adds a point that is easy to miss: a silo is still SaaS only if every tenant is onboarded, managed and deployed through one shared process. If each customer runs a different version with its own procedures, you are operating a managed service, not a SaaS product.

Isolation is a spectrum, not a switch. You can share the application servers while separating the databases, or the reverse. Microsoft describes the choice as commercial as much as technical, because it sets your cost per customer and what you can promise in a contract.

The four main isolation models

1. Shared tables with a tenant ID

All tenants live in the same database and the same tables. Every row carries a tenant identifier, and every query filters on it. AWS calls this the pool model; Google's Spanner documentation calls it the row pattern.

It has the highest density of tenants per unit of infrastructure, so it tends to be the cheapest to run, and there is only one database to patch, back up and monitor (Azure: storage and data approaches). Onboarding a customer is just inserting a record. The trade-offs: separation depends on software being correct, a busy tenant can slow down the others, per-tenant schema changes are difficult, and a single database eventually reaches a size or throughput ceiling. The usual answer to that ceiling is sharding, which spreads tenants across several identical shared databases.

2. Schema per tenant

Tenants share one database server, but each tenant gets its own named set of tables (a schema). AWS's PostgreSQL guidance treats this, along with separate logical databases on one server, as a bridge model, and is direct about its limits: it has the same noisy neighbor concerns as shared tables, and adds provisioning overhead because something must be created for every new tenant (AWS Prescriptive Guidance: PostgreSQL bridge model).

The cloud vendors do not fully agree here. Microsoft lists creating individual tables for each tenant inside one database as an antipattern, on the grounds that it cannot support large numbers of tenants and becomes hard to query, manage and update. A reasonable reading is that schema per tenant can suit a modest number of larger tenants, and becomes a burden as the tenant count grows, because every schema change is applied once per tenant.

3. Database per tenant

One shared application connects to a separate database for each tenant. Data isolation is strong, a tenant's schema can be extended without touching anyone else, and you can restore one tenant to an earlier point in time without affecting others (Microsoft: multitenant SaaS database patterns).

Cost is higher because you provision data resources per tenant, although pooling features, such as elastic pools in Azure SQL Database, let many small databases share capacity. Microsoft is explicit that this model needs automated provisioning. You also need a catalog that maps each tenant to its database, and a way to roll schema changes across the whole fleet.

4. Fully isolated deployments

Each tenant gets its own copy of the entire stack: application servers, database, storage and sometimes its own cloud account or network. Microsoft calls these automated single-tenant deployments. Isolation is the strongest available, tenants are unlikely to affect each other's performance, and updates can be rolled out tenant by tenant.

The price is cost and effort. Microsoft's guidance puts it plainly: if one tenant requires a given infrastructure cost, 100 tenants probably require 100 times that cost. Fleet-wide reporting and upgrades also become engineering projects of their own.

Comparison table

How enterprise customers change the choice

A product can run happily on shared tables until the first large customer sends a security questionnaire. The requests that most often force an architecture change are:

• Data residency. The customer wants its data stored in a specific country or region. Microsoft's Deployment Stamps pattern describes placing customers in regional copies of the system to meet data sovereignty requirements. In practice this means one deployment per region and routing each tenant to the right one.
• Dedicated instances. Some procurement teams will not accept a shared database. AWS notes that some customers do not consider the logical separation of row-level policies sufficient.
• Customer-managed encryption keys and individual backup policies. Microsoft lists both as conditions that push toward isolating a tenant.

US and UK readers face different legal starting points. In the UK, the Information Commissioner's Office explains that sending personal data outside the UK is a restricted transfer that must be covered by adequacy regulations, appropriate safeguards or an exception (ICO guide to international transfers). In the US, residency requirements tend to arrive through customer contracts and sector-specific rules. This is a high-level description and not legal advice; confirm your obligations with a qualified adviser before promising a customer where its data will live.

Isolation can also be a pricing tier: both AWS and Microsoft describe offering dedicated resources to customers who pay more.

Tenant-aware authentication and authorization

Signing a user in is not the same as isolating tenants. AWS states that authentication and authorization are one piece of isolation and not enough on their own, and that enforcement should not be left to individual developers remembering to add a filter (AWS: the isolation mindset). In practice:

• Every request carries a tenant. The identity provider typically adds a tenant identifier to the user's token, and the application uses that, not anything the browser sends, to decide which data is in scope (Azure: identity in multitenant solutions).
• Permissions are scoped to a tenant. A person can be an administrator in one tenant and a read-only user in another, so roles are stored per tenant.
• Enterprise sign-in. Larger customers expect single sign-on through their own identity provider and automated user provisioning, commonly through the SCIM standard. A misconfigured federation must never grant access to another tenant.
• Do not build your own identity system. Microsoft calls this an antipattern because it is complex, expensive and hard to secure.
• Enforce isolation in one shared place, such as a central data access layer or database policy that applies the tenant filter automatically.

Noisy neighbors

The noisy neighbor problem occurs when one tenant's activity degrades performance for others, for example a large customer running a heavy export during everyone else's working hours. It can also happen with no single culprit, when many tenants peak together (Azure: noisy neighbor antipattern). In a shared system it cannot be removed completely, only managed:

• Measure resource use per tenant. A shared database does not know which tenant is consuming resources unless your application records it.
• Apply rate limits and quotas per tenant, and tell customers what they are.
• Cap expensive operations with result-size and query-time limits, and move heavy jobs to background queues at off-peak times.
• Use platform controls where they exist. On Kubernetes, resource quotas keep a tenant from using more than its assigned share (Google Kubernetes Engine: multi-tenancy overview).
• Move persistently heavy tenants to their own shard, database or deployment.

Backups and per-tenant restore

This is the factor teams most often overlook. Backing up a shared database is easy. Restoring one customer who deleted their own records last Tuesday, without rolling back every other customer, is not.

With shared tables, Microsoft notes that restoring a single tenant may require restoring the whole database to a separate resource and then selectively recovering that tenant's data. Google's Spanner guidance makes the same point: with table or row patterns, the application itself must implement per-tenant backup, because the database cannot tell which data belongs to which tenant (Google Cloud: implement multi-tenancy in Spanner). With a database per tenant, a point-in-time restore of one database is a standard operation that touches nobody else.

Whichever model you choose, decide what recovery you will offer customers, test a single-tenant restore before you need one, and plan how a departing tenant's data will be exported and deleted.

Migrating between models

Microsoft warns that switching tenancy model later is sometimes costly. The model is built into queries, connection handling and deployment scripts. A few design habits keep the door open:

1. Put a tenant ID on every table, even with a database per tenant. Microsoft's hybrid model relies on this so a tenant can move into its own database and back without schema changes.
2. Keep a tenant catalog. A central record of which database, shard or deployment holds each tenant lets you move one tenant by copying data and updating one entry.
3. Automate schema changes and track the schema version per tenant.
4. Move one tenant at a time: take it offline or read-only, copy and verify its data, update the catalog, bring it back online, and delete the old copy only after a safe period.
5. Expect moves between isolated deployments to be harder. Microsoft notes they need custom logic, and recommends running at least two deployments from the start so single-deployment assumptions are not hard-coded.

An illustrative scenario, not a client case study: a scheduling product launches on shared tables. Two years in, a hospital group asks for UK-only hosting and its own database. Because the product has a tenant catalog and a tenant ID on every table, the team stands up a UK deployment and moves that one tenant. Without those two things, the same request becomes a rewrite.

For technical readers

• Row-level security is a backstop, not a guarantee. In PostgreSQL, superusers and roles with BYPASSRLS always bypass row security, and table owners normally do too unless FORCE ROW LEVEL SECURITY is set (PostgreSQL documentation: row security policies). Connect the application as a non-owner role. Microsoft adds that propagating tenant identity into every query is complex to build and test.
• Set tenant context per request, and reset it. With pooled connections, a tenant setting left on a reused connection is a leak path.
• Lead primary keys and indexes with the tenant ID, and carry it outside the database too: cache keys, queue messages, file paths, search indexes and logs.
• Write automated tests that attempt cross-tenant access. Microsoft recommends testing any isolation model for both data leakage and noisy neighbor effects.

Frequently asked questions

What is the difference between single-tenant and multi-tenant SaaS?

In single-tenant SaaS each customer has dedicated resources, such as its own database or full deployment. In multi-tenant SaaS customers share resources and are separated logically. Most real products sit between the two, sharing some layers and dedicating others.

Is a shared database secure enough for business customers?

It can be, if tenant filtering is enforced centrally, backed by database policies, and tested. Whether it is acceptable is a separate question that your customers decide. Some industries and procurement teams require a dedicated database however well logical isolation is implemented.

Can we start with a shared database and move large customers out later?

Yes. It is far easier if every table has a tenant ID, a catalog records where each tenant lives, and schema changes are automated.

Does data residency mean every customer needs a separate database?

Not necessarily. A common approach is one deployment per region, each of which can itself be multi-tenant. Backups, logs and identity data need to follow the same commitments as the main database.

Conclusion

There is no single correct tenancy model. Shared tables minimize cost, a database per tenant buys isolation and clean restores, and isolated deployments satisfy the most demanding customers at the highest price. The same options apply whether you build with Laravel, Node.js or another stack. What matters is choosing deliberately and enforcing tenant boundaries in one place.

A useful next step is to write down your expected tenant count, the largest customer you hope to sign, and any residency or compliance commitments, then test each model against that list. If an outside team will build the product, our guide to outsourcing software development from the US or UK covers how to evaluate one. Entrant Technologies builds web applications and custom software; if you would like a second opinion on a tenancy design, get in touch.