Multi-tenant — what it is and how to choose a SaaS architecture for many customers

When you're planning a SaaS product, one of the first architectural decisions sounds innocent: does every customer get its own copy of the application and database, or do they all share one? That second answer is multi-tenant (also "multitenancy"). This one decision determines how much you pay for infrastructure, how fast a fix reaches every customer, what you can tell a large customer who asks about data isolation — and how serious the consequences of a single code bug can be.

This article explains what multi-tenant architecture means according to the norms and the documentation of major cloud providers, which intermediate models AWS and Microsoft describe, how customer data is actually separated in a database in practice, and where that isolation can fail. We rely only on sources you can check — standards, technical documentation, security advisories, and the text of GDPR.

Multi-tenant — what it is

The oldest widely cited definition of cloud computing, NIST SP 800-145 from September 2011, lists resource sharing among the five essential characteristics of cloud computing: "Resource pooling. The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand." (NIST SP 800-145)

So NIST says the multi-tenant model is simply how the cloud works at all. It doesn't say what that model requires, though. That's filled in by the ISO/IEC 17788:2014 standard (identical to ITU-T Recommendation Y.3500), which defines two terms (ITU-T Y.3500):

• multi-tenancy (§3.2.27): "Allocation of physical or virtual resources such that multiple tenants and their computations and data are isolated from and inaccessible to one another.";
• tenant (§3.2.37): "One or more cloud service users sharing access to a set of physical and virtual resources."

The word "tenant" matters. It isn't a single user — it's the unit you isolate — in a typical B2B SaaS, that's the customer company, together with all of its employees. In the ISO definition, the point isn't sharing — it's isolation: resources are shared, but one tenant's data must be inaccessible to another's. The rest of this article is about how you guarantee that, and what it costs.

We explain what cloud computing itself is, and how the IaaS, PaaS and SaaS models differ, separately in our article on cloud computing.

Single-tenant vs multi-tenant — what you gain, what you lose

The two extremes are simple to describe. In a single-tenant model, every customer has its own environment: its own application instance, its own database, often its own servers. In a multi-tenant model, every customer uses the same application and the same infrastructure, and application and database logic separates their data.

The differences show up most clearly in four areas that matter to both a business owner and whoever owns the technology.

Cost. Sharing resources is why SaaS can cost a customer a small monthly fee — a few dozen euros a month, not a new server bill. In single-tenant, every new customer means a new environment to stand up and pay for, even if only five people use it once a week. In multi-tenant, a new customer is a few new rows in a database.

Updates. In the shared model, you ship a fix once and every customer has it immediately. In the separate-environments model, every rollout has to be repeated for every customer — and unless that's fully automated, environments quickly drift to different versions.

Isolation. Here the advantage sits with single-tenant. When each customer's data lives in its own database, a buggy query can't show customer A's data to customer B, because that data simply isn't in A's database. In the shared model, that boundary is drawn by code and database configuration — and every bug in either is a potential cross-customer leak.

Customization. A separate environment is easier to tailor to one customer: a different data-residency region, a different maintenance window, its own domain, sometimes its own extensions. In the shared model, every such difference has to be handled inside one application — usually through per-tenant settings.

AWS flags something easy to forget: even separate environments per customer don't turn a product into a managed service. The SaaS Lens states that "a silo environment still relies on a shared identity, onboarding, and operational experience... This differentiates SaaS from a managed service model" (AWS SaaS Lens). In other words: if every customer's environment is built and maintained differently by hand, that's not SaaS any more — it's custom hosting.

Three models per AWS: silo, pool and bridge

In practice, few products sit entirely on one side. AWS's Well-Architected SaaS Lens describes three models (AWS, "Silo, Pool, and Bridge Models"):

• silo — "The silo model refers to an architecture where tenants are provided dedicated resources.";
• pool — "the pool model of SaaS refers to a scenario where tenants share resources. This is the more classic notion of multi-tenancy";
• bridge — "Bridge is meant to acknowledge the reality that SaaS businesses aren't always exclusively silo or pool."

The bridge model is the most common in practice, though it's rarely called that. A typical example: one shared web application, but separate databases for the customers who need one. Or the reverse — one shared database for everyone, but separate job queues for the customers generating the most traffic.

AWS also has a document dedicated entirely to isolation, "SaaS Tenant Isolation Strategies", from 1 August 2020. Worth knowing, with one caveat: AWS itself now labels it "for historical reference only" (AWS whitepaper). The specific technical solutions it describes may have aged. One sentence remains current and captures the stakes well: "Crossing this boundary in any form would represent a significant and potentially un-recoverable event for a SaaS business."

Four models per Microsoft

Microsoft's Azure Architecture Center approaches the same problem from the deployment side and distinguishes four models (Microsoft Learn, "Tenancy models for a multitenant solution"):

1. Automated single-tenant deployments — "you deploy a dedicated set of infrastructure for each tenant." The word "automated" matters: separate environments only make sense when they come from one template, not a manual process.
2. Fully multitenant deployments — "a fully multitenant deployment in which all components are shared."
3. Vertically partitioned deployments — "Use a combination of single-tenant and multitenant deployments." For example, basic-plan customers land in a shared environment while enterprise customers get their own.
4. Horizontally partitioned deployments — "you have some shared components but maintain other components with single-tenant deployments. For example, you can build a single application tier and then deploy individual databases for each tenant."

Two sentences from that document are worth remembering more than the model names themselves. First: "Instead of viewing isolation as a discrete property, consider it a spectrum." Second: "Selecting a tenancy model isn't only a technical decision. It's also a commercial decision." What you can promise a customer in a contract, and at what price, follows directly from how you built isolation.

How data actually gets separated: a separate database, a separate schema, or shared tables

The most important part of isolation is the data. Whatever the model is called, at the database level you have three basic approaches to choose from.

A separate database for every customer. The strongest logical separation: a query run in customer A's database has no physical access to customer B's tables at all. It's also easy to restore one customer's backup, move them to another region, or delete all their data at the end of a contract. The price is maintenance: every schema change has to be run against every database separately, and the number of connections and costs grows with the number of customers.

A shared database, a separate schema per customer. An intermediate solution: one database instance, but each customer's tables live in their own namespace. Separation is weaker than separate databases, and the schema-migration problem remains — just within one server.

Shared tables with a `tenant_id` column. The classic pool model: every customer's records live in the same tables, and every row carries a tenant identifier. It's the cheapest and simplest to maintain, but Microsoft states its weak point directly: "When multiple tenants share a single deployment... you typically rely on your application code and a tenant identifier that's in a database to keep each tenant's data separate." (Microsoft Learn) One query without a WHERE tenant_id = ... clause, and every customer's data is exposed.

Row Level Security in PostgreSQL — a second line of defense

That's exactly why, in a shared-tables model, it's worth not relying on application code alone. PostgreSQL has a mechanism that moves that control into the database itself — Row Level Security (RLS). Its documentation describes it this way: tables "can have row security policies that restrict, on a per-user basis, which rows can be returned by normal queries or inserted, updated, or deleted by data modification commands. This feature is also known as Row-Level Security." (PostgreSQL, 5.9 Row Security Policies)

In simplified form, for a table with a tenant_id column, that might look like this (a sketch, not production-ready code):

1ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
2ALTER TABLE invoices FORCE ROW LEVEL SECURITY;
3
4CREATE POLICY tenant_isolation ON invoices
5  USING (tenant_id = current_setting('app.tenant_id')::uuid);
Copy

The application sets the tenant identifier for the connection, and the database adds the matching condition to every query on its own. Even if a developer forgets the filter, the database won't return another tenant's rows.

PostgreSQL's documentation gives three rules that decide whether RLS actually protects you:

• Default deny. "If no policy exists for the table, a default-deny policy is used, meaning that no rows are visible or can be modified." Turning on RLS with no policies closes the table — it doesn't open it.
• Superusers, and roles with the BYPASSRLS attribute, always bypass policies. If your application connects as a superuser, RLS simply doesn't apply.
• Table owners usually bypass it too. "Table owners normally bypass row security as well, though a table owner can choose to be subject to row security with ALTER TABLE ... FORCE ROW LEVEL SECURITY." This is a common trap: the application connects as the same role that created the tables, and policies don't apply to it. Hence the second line in the example above.

Supabase: RLS is on only as configured

Supabase is a popular PostgreSQL-based platform many startups use to build an MVP. Here RLS matters even more, because tables can be reached directly from the browser via an API. Its documentation is unambiguous: "A table in an exposed schema without RLS is readable and writable by any role with a grant on it. Enable RLS on every table in an exposed schema." (Supabase, Row Level Security)

Two further traps from the same documentation:

• the service_role key gives "Full access. It bypasses RLS, so keep it server-side" — if it ends up in frontend code, tenant isolation stops existing;
• views: "Views bypass RLS by default because they are usually created with the postgres user." A view built on top of a table with policies can therefore show every row of every customer.

Supabase also notes that adding policies doesn't remove the default grants given to roles ("Adding policies doesn't remove them"). RLS is a second line of defense, not a replacement for thinking through your grants.

Noisy neighbors, and other costs of sharing

Data isolation isn't the only problem with shared infrastructure. The second has a name vivid enough to have stuck in the documentation: the noisy neighbor problem. Microsoft defines it this way: "The noisy neighbor problem occurs when one tenant's performance is degraded because of the activities of another tenant." (Azure Architecture Center, "Noisy Neighbor Antipattern")

In a SaaS product it usually looks mundane: one customer imports a large file, generates a heavy report, or its integration sends thousands of requests a minute — and the application slows down for everyone else. Microsoft adds a sentence worth keeping in mind before you make promises in a contract: "Sharing a single resource inherently carries the risk of noisy neighbor problems that you can't completely avoid."

You can limit it: per-tenant request limits, separate queues for heavy jobs, monitoring each customer's resource usage, and, in extreme cases, moving the largest customer into its own environment — effectively a move to the bridge model. If you plan to promise customers an uptime or response-time guarantee, the noisy-neighbor problem is one of the risks you have to price into those promises (we cover guarantees themselves in our article on SLA).

Other costs of sharing are less visible but real: it's harder to restore one customer's data from a shared database's backup without touching the rest, harder to permanently delete all of one customer's data at the end of a contract, and every database migration touches everyone at once.

When isolation fails: ChaosDB and ExtraReplica

Is multi-tenancy safe? The best answer comes from the cases where tenant isolation was actually broken — at a provider the scale of Microsoft. Researchers at Wiz described two such cases, and Microsoft confirmed them in its own advisories. In both, these are vulnerabilities found by researchers, not confirmed data breaches.

ChaosDB — Azure Cosmos DB, 2021. On 27 August 2021, the Microsoft Security Response Center described a vulnerability in Cosmos DB's Jupyter Notebook feature that "could potentially allow a user to gain access to another customer's resources by using the account's primary read-write key." The issue was reported on 12 August 2021, and Microsoft disabled the preview feature and asked customers who had used it between 7 and 13 August to rotate their keys. The key sentence in the advisory: "No customer data was accessed because of this vulnerability by third parties or security researchers." (MSRC, 27 August 2021) Researchers at Wiz described the potential scope as "complete unrestricted access to the databases of several thousand Microsoft Azure customers"; they received a $40,000 bounty for the report (Wiz, ChaosDB).

ExtraReplica — Azure Database for PostgreSQL Flexible Server, 2022. On 28 April 2022, Microsoft described a vulnerability enabling "unauthorized cross-account database access in a region." Among the causes was "an improperly anchored regular expression to bypass authentication." The vulnerability only affected servers using the public network-access option. Fixes were deployed on 13 January 2022 (tenant isolation) and 25 February 2022 (the whole infrastructure). Microsoft stated: "Our analysis revealed no customer data was accessed using this vulnerability." (MSRC, 28 April 2022; Wiz, ExtraReplica)

Three conclusions for your own product. First, tenant isolation isn't one lock, it's several layers — in ExtraReplica, a single bug in a regular expression was enough to take one of them down. Second, in both cases the boundary broke at an additional point: a preview feature and an optional network-access mode. Any new feature touching multiple customers' data deserves its own security review. Third, to be able to tell customers after a disclosure whether anyone exploited it, you need records that let you determine that. In a small SaaS, that means at minimum logging data access together with the tenant identifier.

GDPR Art. 32 and a multi-customer SaaS

If your SaaS processes personal data on behalf of your customers, you're their processor, and GDPR Art. 32 applies to you directly. Its consolidated text reads, in part:

> Art. 32(1): "Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: (a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing."

>

> Art. 32(2): "... in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed."

It has to be said honestly: Art. 32 doesn't literally require separating tenants, or any specific architecture. What we draw from it is our own interpretation. In a multi-customer SaaS, the most plausible scenario behind the "unauthorised access" language in para. 2 is exactly the situation where one customer sees another's data. Confidentiality under point (b), in a shared model, depends on the quality of your isolation. And point (d) — regularly testing the effectiveness of measures — in practice means tests that check whether one tenant's user can read another tenant's data. Point (c) connects to recovery time after an incident, which we cover in our article on SLA.

We cover the wider split of responsibility between provider and customer, the data-processing agreement, and the questions to ask a cloud provider in our article on cloud data security.

How to choose a model to start with

There's no single right answer, but there are questions that narrow the choice quickly. Worth answering before the first table exists in the database.

Who are your customers, and what will they demand? If you sell to small companies paying a modest subscription, a shared model is usually the only one that works economically. If you're targeting enterprise customers, expect questions about data isolation, data-residency region and audits — sometimes an outright requirement for a separate database. In that case, design the application from the start so it can run in either mode (the bridge model).

How much can you spend on infrastructure per customer? Microsoft is right to call this a commercial decision. A separate environment for a customer paying a small monthly subscription rarely makes sense; for a customer on a large annual contract, it often does.

What scale do you expect? A few dozen customers can be served in any model. At hundreds or thousands of customers, separate databases mean hundreds or thousands of migrations for every schema change.

What regulations and contracts bind you? Particularly sensitive data, industry requirements, clauses in your customers' data-processing agreements — all of these can force a higher level of isolation than you'd choose on cost grounds alone.

For most new products, a sensible starting point is a shared model with shared tables, a tenant-identifier column on every table holding customer data, and Row Level Security as a second line of defense — designed so that a large customer can later be split out into their own database. That architecture is cheap to start with and doesn't close off the path to a bridge model. The most expensive scenario is adding a tenant identifier to an existing application that was never designed with one — then you have to review every single query.

What does building such an application cost? There's no single answer — multi-tenant SaaS sits in the costliest category of custom software builds, alongside ERP/CRM integrations and projects with compliance requirements, mainly because the data model, the permission model and the isolation layer all have to be designed together rather than bolted on afterwards. The practical takeaway is less about a price tag than a sequencing rule: plan the `tenant_id` column from version one, even in the cheapest MVP, so that scaling isolation later doesn't mean rewriting the data model. You can get a rough estimate for your own scope with our web-app cost calculator.

If you're still validating the idea, start with our article on the MVP. For the building blocks a SaaS application needs beyond tenant isolation itself — accounts, payments, roles — see our article on SaaS applications, and for the full business model, our guide to SaaS. We build products as part of our web-app development and MVP for startups services, and if you need an independent opinion on your architecture first, we can help through technology consulting.