Architecture4 February 20268 min read

What is a multi-tenant SaaS platform, and do you need one?

One system, thousands of customers, none of whom can see each other. What multi-tenancy means in practice, what it costs, and the architectural decisions you cannot cheaply undo.

If you are planning to sell software as a subscription, multi-tenancy is the decision that shapes everything else — cost, speed of onboarding, security model and how much of your margin gets eaten by running the thing.

It is also routinely explained badly. Here is what it actually means and how to decide.

The idea, in one paragraph

A multi-tenant platform is one running application and one database serving many separate customers — tenants — each of whom sees only their own data and believes they are using a system built for them. Signing up a new customer creates a record, not a deployment. That is the whole benefit: the cost of adding customer number five hundred is close to nothing.

The alternative, single-tenant, gives every customer their own copy of the application and their own database. Stronger isolation, far more freedom to customise, and an operational cost that grows in a straight line with every customer you win.

How tenants stay separated

Isolation is the part that must be right, because the failure mode is one customer seeing another customer's data — commercially fatal and, under UK GDPR, a reportable breach.

Shared database with a tenant column on every table. Cheapest to run, and every single query must be scoped to the tenant. Enforced at the framework level, never left to individual developers to remember.
Schema per tenant. One database, separate schemas. Stronger separation, moderate operational overhead, migrations must run across every schema.
Database per tenant. Strongest isolation, easiest to back up and restore individually, most expensive to operate at scale.

Whichever you choose, tenant scoping belongs in a layer that cannot be bypassed. "Everyone remembers to add the filter" is not a security model.

The features every SaaS needs and nobody budgets for

The application is the visible half. The other half is what makes it a product rather than a demonstration, and it is the part first-time founders consistently leave out of the budget.

Self-service sign-up, email verification and onboarding that works without you on a call.
Subscription billing — plans, trials, upgrades, downgrades, failed payments, dunning, VAT and invoices.
Roles and permissions inside each tenant, because customers have staff.
A back office for you: impersonation for support, usage visibility, and the ability to fix a customer problem without a database client.
Custom domains or subdomains per tenant, with automated certificates.
Per-tenant configuration — branding, options and settings — without a code change for each customer.
Usage metering if you charge on anything other than seats.

What it costs and how long it takes

A first sellable release — multi-tenant core, sign-up, billing, the main workflow and a usable back office — starts around £18,000 and takes three to five months. That is a product you can charge for, not a prototype.

Adding multi-tenancy to an application that was not designed for it later is substantially more expensive, because it touches the data model, every query, the authentication layer and the entire test suite. This is the decision worth getting right at the start even if the first version only has one customer.

When single-tenant is the right answer

Multi-tenancy is not automatically correct. Choose single-tenant when customers demand their data in a specific jurisdiction or on their own infrastructure, when each deployment genuinely needs different functionality rather than different settings, when you are selling to a small number of large enterprises at high value, or when regulation requires provable physical separation.

The rule of thumb: many small customers at low price points means multi-tenant. Few large customers at high price points can support single-tenant comfortably.

Decisions that are expensive to reverse

Some choices are cheap to change later and some are not. Spend your thinking time on the second group.

Your tenant isolation strategy. Changing it later is close to a rewrite of the data layer.
Whether identity is per-tenant or global. It determines whether one person can belong to two customers.
What you meter and record from day one. You cannot retrospectively bill for usage you never captured.
Your custom domain approach, if customers will want their own branding on it.
Where the money flows. Taking payment on behalf of tenants is a materially different build from charging tenants directly.

The short version

Multi-tenant means one application serving many isolated customers — adding a customer costs almost nothing.
Tenant isolation must be enforced structurally, not by developer discipline.
Billing, onboarding, permissions and an admin back office are half the real build.
A sellable first release starts around £18,000 over three to five months.
Isolation strategy, identity model and usage metering are the decisions you cannot cheaply undo.

Questions people ask about this

Can I start single-tenant and convert to multi-tenant later?

Technically yes, practically it is a major piece of work touching the data model, every query and the authentication layer. If multi-tenant is where you are heading, build it that way from the first release even with one customer.

How do you stop one customer seeing another customer's data?

By enforcing tenant scope in a layer every query must pass through, then testing it deliberately — automated tests that attempt cross-tenant access and fail the build if any of them succeed.