Multi-tenant SaaS architecture: a practical guide (2026)

Multi-tenant SaaS architecture means one running instance of your application serves many customers, with software-enforced boundaries keeping each customer’s data separate. Rather than deploying a fresh copy of the product for every client, you deploy once and partition by tenant. The whole design question comes down to a single decision, repeated at each layer of the stack: do these tenants share this resource, or does each get its own? Get that decision right and you can add a customer for pennies. Get it wrong and you inherit a cost base, or a security problem, that is expensive to unpick later.

What a tenant actually is

A tenant is a customer organisation, not a user. If an accountancy firm signs up and adds forty staff, that is one tenant and forty users. Almost every piece of data in your system belongs to exactly one tenant, and almost every query needs to be constrained to the tenant of the person making the request.

This sounds obvious, yet it is one of the most common causes of serious bugs in the SaaS products we are asked to review. One query that forgets its tenant filter, and Customer A sees Customer B’s invoices. That is a reportable data breach, not a defect.

The three isolation models

There are three common approaches, and most real products end up using more than one at the same time.

Shared database, shared schema (pooled)

Every tenant’s rows live in the same tables, separated by a tenant_id column. This is the cheapest model to run and the fastest to build: one database, one set of migrations, one connection pool.

The risk is that isolation depends entirely on your code being correct every time. Mitigate it at the database rather than in application logic. PostgreSQL row-level security lets you set the tenant on the connection and have the database itself refuse to return rows belonging to anyone else, so a forgotten WHERE clause returns nothing rather than everything.

Shared database, separate schemas (bridged)

One database server, one schema per tenant. Data is genuinely partitioned, backup and restore can be done per tenant, and cross-tenant leakage is much harder to cause by accident. What you gain is data isolation, not resource isolation: every schema still shares the same CPU, memory, disk and connection pool, so a heavy tenant slows the others down exactly as it would in a pooled system.

The cost appears at migration time, because every schema change has to run against every schema. In our experience a few dozen tenants is a manageable script; by the time you are into the hundreds it becomes an engineering problem in its own right, with partial failures and long-running deploys.

Database per tenant (siloed)

Each tenant gets their own database, sometimes their own application instance and their own infrastructure. This is the strongest isolation, the easiest story to tell an enterprise security team, and the only clean answer to “our data must remain in the EU” or “we need our own encryption keys”.

It is also the most expensive per tenant and the slowest to operate. Provisioning, migrations, monitoring and cost attribution all have to be properly automated before you can run more than a handful.

	Pooled	Bridged	Siloed
Cost per tenant	Lowest	Moderate	Highest
Isolation strength	Application-enforced	Schema-enforced	Infrastructure-enforced
Noisy-neighbour risk	High	High (shared server)	Very low
Migration effort	One run	One run per schema	One run per database
Per-tenant restore	Difficult	Straightforward	Trivial
Data residency options	Limited	Limited	Full
Sensible tenant count	Many thousands	Up to a few hundred	A handful to a few dozen

The hybrid is usually the right answer

The models are not mutually exclusive, and treating them as a single global choice is a common mistake. A pattern that works well is to run the great majority of your customers pooled, and offer a siloed deployment as a paid enterprise tier for the few who genuinely need it.

That requires one thing from day one: the tenant must be resolved at the edge of the request, and everything downstream must read it from a single place. If tenant resolution is a well-defined step, moving a tenant into their own database later is a data migration and a routing change. If tenant identity is scattered through your codebase, it is a rewrite. Our guide to choosing a tech stack covers the related groundwork.

You can also split by layer. Pooled application servers with siloed databases is common, as is a pooled database with a per-tenant storage bucket.

Noisy neighbours and how to contain them

In a pooled system, one tenant’s behaviour affects everyone else. A customer who imports two million records at nine in the morning will slow down every other customer on that database. Four controls handle most of it:

• Per-tenant rate limiting on the API, not just per-user. A tenant with three hundred staff should not consume the whole budget.
• A separate queue and worker pool for heavy jobs, so bulk imports and reports cannot starve interactive requests.
• Query cost limits, including statement timeouts and enforced pagination. Unbounded queries are how one tenant takes down a shared database.
• Sharding by tenant once a single database is no longer enough.

Per-tenant configuration without forking the product

Customers will ask for changes. The discipline that keeps a SaaS product profitable is turning those requests into configuration rather than code branches. Keep custom behaviour in three categories: settings (feature flags, limits, workflow options), theming (logo, palette, sender domain), and extension points (webhooks and an API). Anything that will not fit into those three either becomes a feature for everyone, or you decline it.

The moment you maintain a per-tenant fork of your codebase, you have stopped selling software and started selling bespoke development at SaaS prices. If a client genuinely needs a system of their own, that is a legitimate outcome, but it belongs in bespoke software development, not in your SaaS platform.

Onboarding, migrations and observability

Three operational areas decide whether a multi-tenant platform is pleasant or painful to run.

Provisioning should be a single automated action creating the tenant record, any per-tenant infrastructure, the first administrator and seed data. If a person has to run a script to onboard a customer, your sales cycle depends on that person being available.

Schema migrations must be backwards compatible and deployed in stages: add the new column, write to both, backfill, switch reads, remove the old one. In a pooled database you cannot take an outage for one customer, so every migration must be safe with the old code still running.

Observability must be tenant-aware. Every log line, trace and metric should carry the tenant identifier. Without it, “the app is slow” is unanswerable. With it, you can see that it is slow for one tenant, on one endpoint, because of one query, and you can work out what each customer costs you to serve.

What this means for budget

Multi-tenancy is an investment made early to reduce cost later. A pooled platform built properly costs more to design than a single-tenant application, and far less to run once you are serving customers in any real number. The exact point at which it pays back depends on your hosting costs and how much of your operations you have automated.

Building a genuine multi-tenant SaaS platform in the UK typically sits in the £50,000 to £150,000 range for a focused first version, and above £150,000 where you need enterprise isolation options, complex permissions or regulated data handling. Our cost estimator gives an indicative figure, and the SaaS development lifecycle guide sets out how the phases fit together.

Frequently Asked Questions

What is multi-tenant SaaS architecture?

Multi-tenant SaaS architecture is a design where a single deployed instance of an application serves multiple customer organisations, called tenants, with data and configuration kept separate for each. Instead of running a separate copy of the software for every client, the provider runs one system and partitions it by tenant. This lowers hosting and maintenance costs, makes updates simpler because everyone runs the same version, and allows new customers to be onboarded automatically.

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

In single-tenant SaaS, each customer gets their own dedicated instance of the application and its database. In multi-tenant SaaS, customers share infrastructure and are separated by software boundaries such as a tenant identifier, a schema or a per-tenant database. Single-tenant gives stronger isolation and easier data residency compliance at a much higher cost per customer. Multi-tenant is cheaper to run and faster to update, but requires disciplined engineering to prevent data leaking between tenants.

How do you keep tenant data separate in a shared database?

The reliable approach is to enforce separation at the database rather than relying on application code. In PostgreSQL, row-level security policies tied to a session variable mean the database itself refuses to return rows belonging to another tenant, so a missing filter in application code returns nothing rather than someone else’s data. Combine that with a tenant identifier on every table, tenant resolution at the edge of each request, and automated tests that specifically attempt cross-tenant access.

When should you give a customer their own database?

Give a customer their own database when regulation, contract or scale demands it: data residency requirements in a specific jurisdiction, customer-managed encryption keys, an enterprise security review that will not accept shared storage, or a tenant whose data volume degrades performance for everyone else. Price it accordingly, because the cost of running and migrating an isolated deployment is real and ongoing. For most customers, a well-built pooled model is both cheaper and easier to support.

Can you change your multi-tenancy model later?

Yes, but the difficulty depends on decisions made at the start. If tenant identity is resolved in one place and passed explicitly through your application, moving a tenant from a shared database to a dedicated one is a data migration plus a routing change, which is a manageable piece of work. If tenant context is inferred inconsistently across the codebase, changing the model tends to mean rebuilding significant parts of the system. Design the tenant boundary early even if you do not need isolation yet.

How much does a multi-tenant SaaS platform cost to build in the UK?

A focused first version of a genuine multi-tenant SaaS platform generally falls between £50,000 and £150,000, with more complex products involving enterprise isolation, detailed permission models or regulated data typically starting at £150,000. The multi-tenancy work itself is a modest part of that total; most of the budget goes on the product features, integrations and the administrative tooling needed to run a subscription business.

Getting the foundations right

In our experience, many of the multi-tenant problems we are called in to fix were not caused by choosing the wrong model. They were caused by never deciding at all, and letting tenant separation emerge accidentally from whatever each feature happened to do.

If you are planning a platform, or you have one straining as customer numbers grow, our SaaS development team can review the architecture and set out the options honestly. Have a look at how we work, or get in touch.