Multi tenant or single tenant, and which layer you isolate

The question arrives early and gets answered late. Somebody asks whether each customer should get their own copy of the system or share one, the team says it depends, and the decision is made six months later by whoever is writing the database migration that week. By then it is expensive to change.

It is worth deciding properly, because the two cloud vendors who host most of this software have both written down the trade offs, and their guidance agrees on the shape of the answer: this is a commercial decision before it is a technical one, and the right answer is usually not either extreme.

What the two words actually mean

A tenant is a customer. Single tenant means each customer gets their own deployment: their own database, often their own compute, sometimes their own cloud account. Multi tenant means customers share one deployment and are kept apart by the application code and a tenant identifier on every row.

Microsoft's Azure Architecture Center guidance on tenancy models makes a point worth repeating before anything else: isolation is not a switch. It describes a continuum "from fully isolated (shared nothing) to fully shared (shared everything)", and says you can place different layers of one system at different points on it. Your web tier can be shared while your databases are separate.

That is the detail that dissolves most of the argument. The real question is not which of two models you pick. It is which layer you isolate.

The four models, as the vendors describe them

Azure's page names four patterns rather than two, and they are a more honest map of what teams actually build.

Amazon reaches the same place with different words. Its SaaS Tenant Isolation Strategies whitepaper calls them silo, pool and bridge, where bridge is the hybrid that applies silo or pool per resource. Honest note on that document: it is dated 2020 and some pages on it now carry a banner saying it is retained for historical reference and may be out of date. The model vocabulary is still the vocabulary everyone uses, but do not treat its specifics as current.

The noisy neighbour problem is the one you will actually meet

Teams worry about data leaking between customers, and they should, but the failure that happens most often is duller. One customer runs a report over three years of data on a Tuesday morning and everybody else's application gets slow.

Azure names this directly, saying that in a shared deployment "if a large tenant tries to perform a heavy query or operation, it might affect other tenants", and that horizontally partitioned deployments "can help you mitigate a noisy neighbor problem" because the component carrying the load is the one you separate. That is the useful read: if you can name which component takes the load, you do not need full single tenancy to fix it. You need that component split.

There is a second, quieter version of the same problem: scale limits. Azure warns that a single shared database run at high scale can exhaust its throughput, and that "the costs of scaling might increase nonlinearly". A shared design that is cheap at ten customers is not automatically cheap at four hundred.

What actually forces single tenancy

In practice three things force it, and none of them is a preference.

• A regulator or a contract. Where data must stay in a jurisdiction, or a customer's own compliance regime requires physical separation, the decision is made for you. Azure puts this first among its commercial questions: "Consider whether your customers will accept all forms of multitenancy."
• Per customer configuration that reaches the data model. Different fields, different workflows, different retention rules. Shared schemas absorb a surprising amount of this, and then stop absorbing it abruptly.
• A small number of large customers. Azure is explicit: "if you expect that your business will have only a few customers, you might want to consider using single-tenant resources". Ten enterprise accounts is a different business from ten thousand small ones, and the hundred times cost multiplier only hurts when there are hundreds.

Data residency is the one that catches teams selling into the Gulf, and it is worth understanding as a commercial constraint rather than a technical one. Our Arabic note on how Saudi companies choose a CRM covers that side of it from the buyer's point of view, including why moving data outside the Kingdom is one of two constraints that get checked before any feature list. It is in Arabic.

What it costs you to get this wrong in each direction

Choosing full single tenancy too early is the more common error in small teams, and it is the one that does not announce itself. Nothing breaks. You simply find that every release is a fleet operation, every customer is on a slightly different version, and you cannot answer a question about all customers without querying every deployment. Azure flags exactly that: plan for "how you can query and manipulate data across multiple deployments".

Choosing full multi tenancy too early fails in the other direction and more loudly. The first enterprise customer asks the isolation question in a security review, and the answer takes six months of work you had not planned. If you expect to sell to buyers who run security reviews, the vertically partitioned model exists for precisely this: share by default, offer a dedicated deployment at a higher price, and Azure notes you "can even charge customers a higher rate to use a single-tenant deployment".

If you are at the earlier decision of whether to build the thing at all, that is a different question and it comes first: custom software against off the shelf sets the order to answer it in, and the five year total on a custom build is the number this architecture choice moves most.

A decision you can make in an afternoon

Four questions, in this order, and the answers point at a model rather than at a debate.

• How many customers in three years: tens, or thousands? Tens tolerates isolation. Thousands does not.
• Will any customer contractually require separation, or require data to stay in a country? If yes, you need the vertically partitioned model whatever else is true.
• Which single component will carry the heaviest per customer load? That is the one to separate first, and often the only one.
• Can you deploy and migrate a new tenant without a person doing it by hand? If not, single tenancy will cost more than the infrastructure bill suggests, and that gap is where the hours go.

Write the answers down next to the requirements rather than in a chat thread. The short form of that document is covered in the short requirements document, and tenancy belongs in it because it is the decision that is most expensive to revisit.

Two operational consequences follow from whichever model you pick, and both are easy to forget at the design stage. Enterprise buyers will ask how their users sign in, which is covered in whether single sign on is worth it yet. And restoring one customer's data without touching anybody else's is much harder in a shared database than in a separate one, which belongs in the backup strategy rather than being discovered during an incident.

Honest limits

There is no cost table here, deliberately. Both vendors describe the direction of the cost difference and neither publishes a number, because it depends on your resource mix, your region and your commitments. Anyone quoting you a per tenant figure for a design they have not seen is guessing.

This is two vendors' guidance, not a neutral survey. Microsoft and Amazon both sell the infrastructure these models run on. Their documentation is unusually specific and it is also written by interested parties, and the AWS paper in particular is five years old and labelled as such.

If you genuinely cannot answer the three year customer count, do not pick the extreme. The hybrid models exist for uncertainty. Starting shared with one component separable, and a documented path to a dedicated deployment, costs a little more today and buys back the decision you do not yet have the information to make.