Short answer: in a multi-tenant system, many customers (tenants) share one copy of the software and the same infrastructure, and the provider keeps each customer’s data separate with software controls. In a single-tenant system, each customer gets its own dedicated copy, usually with its own database and sometimes its own servers. Multi-tenant is cheaper and easier to update; single-tenant gives stronger isolation and more control, at a higher cost. Most modern SaaS products are multi-tenant, and many offer a single-tenant option for large or regulated customers.
If you are buying software, the tenancy model affects your price, your security review and how much you can customise. If you are building SaaS, it is one of the earliest architecture decisions you make, and one of the hardest to undo. Microsoft’s own SaaS guidance warns that switching to a different tenancy model later can be costly.
This guide explains both models in plain English, compares them side by side, shows the common middle-ground designs, and gives a simple way to choose. Facts were checked against NIST, AWS and Microsoft documentation in November 2026.
Key takeaways
- A tenant is a customer, usually a whole organisation with many users, not a single person.
- Multi-tenant means shared: one application and usually one database serve many customers, with each customer’s data kept apart by the software.
- Single-tenant means dedicated: each customer gets its own instance of the application and its own database, and sometimes its own hardware.
- Multi-tenant wins on cost and speed of updates. Single-tenant wins on isolation, customisation and control over upgrade timing.
- Most real products are a mix. AWS calls this the bridge model: some parts shared, some parts dedicated.
- Shared does not mean unsafe, but it does mean one bug in tenant isolation can affect many customers at once.
What is a tenant?
In cloud and SaaS, a tenant is one customer account and everything that belongs to it: its users, settings and data. If a company with 200 employees signs up for a CRM, that company is one tenant, not 200.
Sharing is built into the cloud. The US National Institute of Standards and Technology (NIST) lists resource pooling as one of the five essential characteristics of cloud computing, and describes it as a provider’s resources being pooled to serve many consumers using a multi-tenant model. So the question is rarely whether anything is shared. It is how much is shared, and at which layer.
What is multi-tenant architecture?
In a multi-tenant architecture, one running copy of the application serves every customer. Tenants usually share the same servers and often the same database tables, and every record carries a tenant ID so the application only ever shows a customer its own data.
A simple way to picture it is an apartment building. Everyone shares the building, the lifts and the plumbing, but each household has its own locked flat. Salesforce uses this same apartment comparison to explain its platform, where all customers run on shared infrastructure and the same version of the software, and upgrades reach everyone automatically at the same time.
Most SaaS tools you use daily, such as CRMs, email, project management and accounting apps, work this way. If you are comparing SaaS with running software yourself, our guide to SaaS vs on-premise covers the wider trade-offs.
What is single-tenant architecture?
In a single-tenant architecture, each customer gets its own instance of the application and its own database. Nothing in the application layer is shared with other customers. Using the same comparison, it is a detached house rather than a flat.
Single-tenant can be hosted by the vendor in the cloud, run in the customer’s own cloud account, or installed on the customer’s own servers. It is also possible to make the hardware single-tenant. On AWS, for example, Dedicated Instances run on hardware dedicated to a single AWS account, and Dedicated Hosts give you a whole physical server. Even then, AWS notes that the EBS storage volumes attached to Dedicated Instances do not run on single-tenant hardware, which shows how carefully you need to read what “dedicated” covers.
Multi-tenant vs single-tenant: side-by-side comparison
| Factor | Multi-tenant | Single-tenant |
|---|---|---|
| Cost per customer | Lowest, because servers and databases are shared | Higher, because each customer needs its own resources |
| Data isolation | Logical, enforced by software (tenant IDs, access policies) | Stronger, with a separate database and often separate infrastructure |
| Performance | Can be affected by busy tenants (the noisy neighbour problem) | Predictable, because resources are not shared |
| Updates | One release updates every customer at once | Each instance is upgraded separately, often on the customer’s schedule |
| Customisation | Mostly configuration and settings | Deeper changes are possible, including custom code and schema changes |
| Onboarding a new customer | Fast, often instant self-signup | Slower, because an instance must be provisioned |
| Compliance and data residency | Possible, but depends on the vendor’s controls | Easier to prove, and data can live in a chosen region or account |
| Backup and restore | Restoring one tenant from a shared database is harder | Each customer can be backed up and restored on its own |
| Blast radius of a failure | One bug or outage can affect many customers | Problems are usually limited to one customer |
| Operating effort for the vendor | Low: one system to monitor and patch | High: many systems to monitor, patch and keep in sync |
Advantages and disadvantages of multi-tenant
Advantages
- Lower cost. Microsoft’s SaaS database guidance notes that multi-tenant databases generally have the lowest cost per tenant, because resources are shared.
- One version to maintain. Bug fixes and new features reach every customer in one release.
- Fast, self-service onboarding. A new tenant is often just a new row in a table.
- Efficient use of capacity. Customers rarely peak at the same moment, so shared resources sit idle less often.
Disadvantages
- Noisy neighbours. Microsoft’s Azure Architecture Center describes this as one tenant’s activity slowing down others, and says the risk cannot be fully eliminated in a shared system, only reduced.
- Isolation depends on code. A single missing tenant filter in a query can expose one customer’s data to another.
- Limited customisation. Customers usually cannot change the core product or delay an upgrade they do not want.
- Harder per-customer operations. Restoring, exporting or moving one tenant’s data out of a shared database takes extra tooling.
Advantages and disadvantages of single-tenant
Advantages
- Strong isolation. Separate databases make accidental cross-customer access far less likely, which helps security reviews and audits.
- Predictable performance. No other customer competes for the same resources.
- Control over change. Customers can test and schedule upgrades, which matters for regulated or heavily integrated systems.
- Easier data residency. An instance can be placed in a specific region, in the customer’s own cloud account, or alongside private infrastructure in a hybrid cloud setup.
Disadvantages
- Higher cost. Each customer pays for resources even when they sit idle, and vendors usually price single-tenant plans higher.
- More work to run. Every instance must be patched, monitored and backed up. With hundreds of customers, this becomes a serious operations burden.
- Version drift. If customers delay upgrades, the vendor ends up supporting many versions at once.
- Slower onboarding. New customers wait while their environment is provisioned.
The middle ground: silo, pool and bridge models
In practice, few SaaS products are purely one or the other. AWS’s SaaS guidance uses three terms that are useful for any provider:
- Silo model: a tenant gets dedicated resources, such as its own database or even its own full infrastructure stack. This is single-tenant at that layer.
- Pool model: tenants share resources such as compute, storage and messaging. This is multi-tenant at that layer.
- Bridge model: a mix, where some parts of the system are shared and others are dedicated. For example, every tenant may share the web tier while each has its own database.
The same idea applies to the database alone. Microsoft describes three common patterns for SaaS data:
| Database pattern | How it works | Best for |
|---|---|---|
| Shared database, shared tables | All tenants in the same tables, separated by a tenant ID column | Many small customers and the lowest cost |
| Database per tenant | A multi-tenant application, but each tenant has its own database | Strong data isolation with one shared codebase |
| Single-tenant application and database | A full, separate deployment for each customer | Large or regulated customers with strict requirements |
Database per tenant is more practical than it sounds. Azure SQL Database, for example, can place many tenant databases in an elastic pool so they share capacity, and Microsoft says its management features can handle well over 100,000 databases. A common commercial pattern follows from this: pooled resources on standard plans, dedicated resources on enterprise plans.
Is multi-tenant secure?
It can be, but security depends on how well tenant isolation is built and tested. A real example shows why it matters.
In August 2021, researchers at Wiz found a flaw in Microsoft’s Azure Cosmos DB, which they named ChaosDB. It could have let one Azure customer gain full read, write and delete access to other customers’ databases. Wiz reported it to Microsoft on 12 August 2021, Microsoft disabled the affected notebook feature within about 48 hours, and Microsoft said it found no evidence that anyone other than the researchers had used the flaw. Wiz’s later analysis traced the issue to several isolation gaps, including a shared certificate that tenant-assigned machines could reach.
The lesson is not that shared systems are unsafe. Hyperscale clouds are shared, and their isolation is heavily engineered. The lesson is that in a multi-tenant system, one isolation failure can affect thousands of customers at once, so it must be enforced in more than one layer. Good practices include:
- Enforce tenant filters in the database, not only in application code. PostgreSQL row-level security (available since version 9.5) and Azure SQL row-level security can block rows from other tenants even if a query forgets its filter. Note that in PostgreSQL, superusers and table owners bypass these policies unless they are forced to apply.
- Carry the tenant ID in a verified token, such as a signed login token, rather than trusting a value sent by the browser.
- Encrypt each tenant’s data with its own key where the risk justifies it, so a leaked shared key cannot unlock everyone.
- Test for cross-tenant access in automated tests and penetration tests, not just normal functionality.
- Set per-tenant limits on requests and resources to reduce noisy neighbour problems.
For a wider view of risks such as misconfiguration and weak identity controls, see our guide to top cloud security issues.
How to choose: a simple decision guide
If you are building SaaS, start multi-tenant unless you have a clear reason not to. It keeps costs and operations manageable while you grow. Choose the pool or bridge model so you can offer a dedicated database or deployment later to the customers who need it, and charge for it.
If you are buying software, multi-tenant is usually the right default. Ask for single-tenant (or a dedicated option) when one or more of these is true:
- A regulator, contract or customer requires physical or account-level separation of your data.
- You need your data stored in a specific country, region or your own cloud account.
- You need to control when upgrades happen, for example because of complex integrations.
- You need deep customisation that a shared product cannot offer.
- Your workload is large and steady enough that predictable performance is worth the extra cost.
Questions worth asking any SaaS vendor:
- Is the application multi-tenant, and is the database shared, per-tenant or dedicated?
- How is tenant isolation enforced and tested, and do independent audits or penetration tests cover it?
- Can I choose the region where my data is stored?
- Can you restore or export only my data, and how long does it take?
- Is a dedicated or single-tenant option available, and what does it cost?
Tenancy also affects your costs over time. Dedicated plans and data moving between regions add up, so it helps to understand cloud egress fees and to keep track of every tool with good SaaS subscription management.
Where tenancy fits with IaaS, PaaS and SaaS
Tenancy applies at every layer of the cloud. An IaaS provider shares physical servers between customers, a PaaS provider shares its platform, and a SaaS vendor shares its application. A single-tenant SaaS product can still run on multi-tenant IaaS underneath, so it is worth asking which layer a vendor means when it says “dedicated”. Our guide to IaaS vs PaaS vs SaaS explains the layers.
Frequently asked questions
What is the difference between multi-tenant and single-tenant?
Multi-tenant software serves many customers from one shared instance and keeps their data separate with software controls. Single-tenant software gives each customer its own instance and database. Multi-tenant is cheaper and simpler to update; single-tenant offers stronger isolation and more control.
Is multi-tenant or single-tenant better?
Neither is better in every case. Multi-tenant suits most businesses because it costs less and updates automatically. Single-tenant suits customers with strict compliance, data residency, customisation or performance needs.
Is Salesforce multi-tenant?
Yes. Salesforce describes its platform as multitenant: all customers share the same infrastructure and the same version of the platform, and upgrades are released to everyone at the same time.
Is single-tenant more secure than multi-tenant?
Single-tenant gives stronger isolation by design, because customers do not share a database or application instance. But a well-built multi-tenant system with layered isolation can be very secure, and a poorly managed single-tenant system can still be breached.
What is a noisy neighbour in multi-tenant systems?
It is when one tenant uses so many shared resources that other tenants see slower responses or failed requests. Providers reduce it with per-tenant limits, monitoring and, for big customers, dedicated resources.
Can a SaaS product offer both models?
Yes, and many do. A common approach is a shared, multi-tenant service for standard plans and a dedicated database or deployment for enterprise customers. AWS calls this mix the bridge model.
Is AWS multi-tenant?
By default, yes. EC2 instances run on shared hardware, with each customer isolated from the others. AWS also sells Dedicated Instances and Dedicated Hosts for customers who need hardware that is not shared with other AWS accounts.
Sources
- NIST SP 800-145: The NIST Definition of Cloud Computing
- AWS SaaS Lens: Silo, pool and bridge models
- AWS: Amazon EC2 Dedicated Instances
- Microsoft: Multitenant SaaS database tenancy patterns
- Microsoft Azure Architecture Center: Noisy Neighbor antipattern
- Salesforce: The Salesforce Platform multitenant architecture
- Salesforce Admins: The apartment analogy for multitenancy
- Data Center Knowledge: Azure Cosmos DB vulnerability (ChaosDB)
- Wiz PEACH framework: ChaosDB case study
- PostgreSQL: Row security policies
