Why SaaS Is Multi-Tenant, and What It Means for Your Data

Few companies using SaaS realise this: your customer records and order data very likely run on the same system — possibly the same database — as the data of hundreds of other companies. Sounds unsettling? It is the standard practice of the entire SaaS industry, and it has a name: multi-tenancy.

Multi-tenancy is not corner-cutting. But any business that keeps its data in SaaS should understand three things: what it is, why vendors all build this way, and where you should ask harder questions.

One apartment building explains it all

Picture an apartment building. Residents share the structure, the lifts, the plumbing and the property management — yet every household has its own door and its own lock. Neighbours cannot see into your home, and you cannot walk into theirs, even though everyone lives under one roof.

Multi-tenancy is the software version of that building. One system serves all customers, and each company is a 'tenant': data and configuration are isolated from one another — walls and locks — while the underlying servers, code and operations are shared — one building, one property team.

The alternative is the detached villa: a separate deployment for each customer, usually called private or on-premise deployment. It feels solid — and the construction, utilities and repairs are all on your own bill.

Why vendors choose the apartment building

First, cost sharing. One system serving a thousand customers spreads servers, bandwidth and operations staff thin across all of them. It is one of the fundamental reasons SaaS subscriptions can be priced low — the other half of that arithmetic is in What Is SaaS.

Second, upgrade efficiency. The property team replaces one lift and the whole building benefits; the vendor ships one release and every customer opens the new version next morning. With a thousand villas, every renovation is a separate job, versions fragment, and response times stretch accordingly.

Third, security maintenance. One vulnerability means one patch for the apartment building — or a thousand house calls across the villas. Multi-tenancy is not the vendor being lazy; it is the precondition for the business model to exist. Without it, neither the pricing nor the pace of SaaS would be possible.

What you, the resident, should actually care about

The sense of safety in an apartment depends on the quality of the walls and locks — not on whether neighbours exist. As a tenant, four concrete things deserve your attention.

One: how isolation is implemented. Logical isolation (one database, rows separated by tenant ID) or a separate database per customer? Logical isolation is the industry mainstream and, done well, is safe enough — but you are entitled to know which approach the vendor uses and how the boundary is enforced.

Two: backup and recovery. How often is data backed up? If someone deletes by mistake, can it be restored? And at what granularity — rolling back the whole building, or precisely your own unit?

Three: whether a neighbour's trouble spills over to you. If another tenant is attacked, or suddenly generates enormous traffic, does your system slow down or go under? In technical terms this is resource and fault isolation, and a mature vendor should be able to explain its approach in plain words.

Four: your options when you outgrow the flat. Past a certain data volume or sensitivity, can you move from the apartment into a villa — does the vendor offer dedicated deployment or a private instance? And when you move, does your data migrate out complete?

Three questions to bring to the vendor meeting

Compress all of the above into three questions you can ask out loud. 'How is our data isolated from other customers' — can you explain the mechanism in plain terms?' 'After the contract ends, how do we export everything, how long do you retain it, and how is it deleted?' 'When failures happen, how do you contain the blast radius — and have you had incidents that affected multiple customers?'

None of these require technical knowledge, but the specificity of the answers is a fair read on the vendor's engineering maturity. A vendor that can explain isolation, backups and failures clearly is usually a safer home for your data than the unattended server in the corner of your office.

Apartment or villa is not a moral question

Multi-tenant SaaS and private deployment have no absolute winner. The former is cheaper, lighter to run and evolves faster; the latter is more controllable with clean compliance boundaries, at the price of carrying every cost and duty yourself. For most small businesses the sensible starting point is the former; industries with high data sensitivity or hard compliance requirements are the ones that owe the latter a serious look — the fuller trade-off is discussed in on-premise deployment and smaller models.