Multi-Tenant Software: How It Really Works

Ask a vendor where your data lives and you often get a confident answer about the data centre. Ask whether another customer’s records sit in the same database table as yours and the answer slows down. That pause is the whole subject of this article.

Nearly every business tool you pay for monthly is shared. One codebase, one set of servers, thousands of companies. The savings are real and they are passed to you in the price. So is a category of risk most buyers never ask about.

This guide explains how multi-tenant software works, the isolation models behind it, what it means for your security and performance, and the questions worth asking before you sign.

What is multi-tenant software?

Multi-tenant software serves many customers from one running instance of an application. Each customer, called a tenant, sees only their own data and settings. Underneath, they share the same code, the same servers and often the same database. The separation is enforced by software rather than by hardware.

Think of an office building rather than a housing estate. Everyone shares the foundations, the lifts and the plumbing. The locks on each door are what make it tenable. In software, those locks are lines of code, and code can contain mistakes.

How does one system keep customers separate?

Every record carries a tenant identifier, and every query filters on it. The application layer adds that filter automatically, so a developer cannot forget. Well built systems enforce it a second time in the database using row level security, so a bug in the application does not become a breach.

Single enforcement is the weak pattern. One missing filter in one endpoint and customer A sees customer B. Cross tenant data exposure keeps appearing in disclosure reports for exactly this reason, and it maps directly to broken access control in the OWASP Top Ten.

What are the isolation models?

Four models sit on a spectrum from cheapest to most isolated. Shared tables, shared database with separate schemas, a database per tenant, and a full stack per tenant. Vendors mix them, commonly putting small customers in shared tables and large regulated ones in dedicated databases.

Both major cloud providers document these patterns in the open. The Microsoft multitenant architecture guidance is the most readable version, and it is useful for buyers, not only builders.

Why do vendors choose it?

Because the alternative does not survive contact with arithmetic. Running a separate copy for every customer multiplies servers, deployments, patching and support. Sharing one instance means one upgrade reaches everyone at once, and the cost of serving each additional customer falls close to nothing.

That economics is why your project tool costs 12 dollars a month instead of 12,000 dollars a year. It also shapes the whole business model, which is covered in how SaaS companies make money. Shared infrastructure is the reason those margins exist.

What does it cost you as a customer?

You give up control of timing and depth. Upgrades arrive on the vendor schedule because everyone runs the same version. Customisation stops at configuration, since your changes cannot alter shared code. Performance depends partly on what other tenants are doing right now.

Most buyers accept that trade without noticing they made it. The version you use is the version everybody uses, which is exactly why the price is low. The wider comparison sits in cloud software and SaaS versus traditional software.

What is the noisy neighbour problem?

One tenant consuming heavy resources slows the platform for everyone sharing it. A single customer running an enormous report or importing millions of rows can degrade response times across the estate. Mature platforms prevent this with rate limits, query timeouts and per tenant resource quotas.

Ask directly how a vendor handles it. A specific answer mentioning quotas or throttling means they have met the problem. A reassuring answer about scaling automatically usually means they have not, and the operational reality is described in how SaaS scales servers.

What breaks at scale?

Three things, predictably. Database migrations become dangerous because one schema change touches every customer. Debugging gets harder because you cannot reproduce a problem without the tenant context. Restoring one customer’s data from backup becomes an engineering project rather than a button.

1. Migrations. A slow change locks tables for everyone at once, so releases become carefully staged events.
2. Selective restore. Pulling back one tenant from a shared database means extracting rows, not restoring a file.
3. Regional rules. A customer requiring data to stay in one country forces a separate deployment.
4. Large tenants. One customer ten times bigger than the rest distorts every performance assumption.

Point three is why vendors add regional instances rather than one global system, a constraint explained in how SaaS stores user data.

When is single tenant the right answer?

When regulation demands physical separation, when you need a version frozen for validation, when data must remain in a specific country, or when your usage is so large that sharing hurts you rather than helping. Outside those cases, single tenant mostly buys reassurance at a considerable price.

An unpopular opinion, stated plainly. Many enterprise buyers pay a large premium for dedicated deployments and receive worse security, because that isolated instance gets patched on a slower cycle than the shared platform. Isolation without operational discipline is a downgrade wearing a suit. Building the platform properly from the start, as in our Orbit multitenant work, matters more than the label.

What should you ask a vendor?

Five questions separate a serious platform from a hopeful one. How is tenant separation enforced. Is it enforced in the database as well as the application. Can you restore my data alone to a point in time. What limits stop one tenant affecting others. Has cross tenant exposure ever occurred and what changed afterwards.

The last question is the most revealing. Every long lived platform has had a scare. A vendor who describes one honestly and explains the fix is telling you more than a vendor with a spotless story. Pair those answers with the checks in SaaS security before signing anything.

What should you read next?

• What is SaaS infrastructure
• How SaaS hosting works
• What is vertical SaaS
• Service: Custom web development

N

Written by

Nick James

DevInfuse