Multi-tenant SaaS: what it means when a vendor says it

Multi-tenant SaaS means one running copy of the software serves many customers, with each customer's data kept apart by the software rather than by separate installations. Your hospital and another hospital use the same servers and the same code, but each sees only its own records. It is how most modern business software is built, including ours. What the phrase does not tell you is how the separation is done, how settings vary per customer and what happens to your data in a backup, and those are the things to ask about.

What is a tenant?

A tenant is one customer organisation: a hospital, a lab, a gym chain. Everything inside the software belongs to a tenant. Users, records, settings, files and reports all carry a tenant identity, and every query the software runs is restricted to the tenant of the person asking. In Healthixio a tenant is a hospital, and a hospital group is a tenant with several branches under it. That last point matters: ask whether a branch is a tenant or a part of one, because it decides whether head office can see consolidated reports.

How is data isolation actually done?

There are three common ways to keep tenants apart, and vendors rarely say which one they use unless asked.

None of these is wrong. What matters is that the vendor can name theirs, explain how a bug in the code is prevented from showing one tenant's data to another, and show the tests that prove it. A tenant filter enforced in one place, in the data layer, is far safer than one that every developer must remember on every screen.

What does per-tenant configuration mean?

Multi-tenant does not mean identical. Each tenant needs its own settings: letterhead and logo, tax rates, departments, roles and permissions, report formats, WhatsApp templates, working hours. The question is how far configuration goes before it becomes custom code. A good multi-tenant product handles the common variations as settings a tenant admin can change, and the vendor handles the rare ones as feature flags turned on for specific tenants. Be wary of a vendor who promises a code change just for you inside a shared product. Either it becomes a feature for everyone, or it becomes a fork that falls behind.

• Settings you should be able to change yourself: branding, users, roles, master lists, templates, numbering formats.
• Settings the vendor changes for you: feature flags, integration credentials, plan limits.
• Things that should never vary per tenant: security rules, audit logging, backup schedules.

How do backups work when everyone shares a database?

In a shared database, the backup is of everything. That is fine for disaster recovery: if the server dies, all tenants come back together. It is less fine when one tenant needs something restored. If a staff member deletes a month of records on Tuesday, can the vendor restore your data to Monday without rolling back every other customer? That needs either per-tenant backups or a way to extract one tenant from a full backup and replay it, and the vendor should be able to describe which one they have and how long it takes.

Ask also about export. A tenant should be able to get all of its data out in a documented format, at any time, without asking for a favour. This is both a practical safeguard and part of what the Digital Personal Data Protection Act expects of a business that holds personal data on other people's behalf.

What should you ask a SaaS vendor?

1. Which isolation model do you use, and where in the code is the tenant filter enforced?
2. Can you show a test that proves one tenant cannot read another tenant's records?
3. Where are the servers, and is my data stored in India?
4. What can I change myself, and what needs a ticket?
5. If we delete something by mistake, can you restore only our tenant, and to what point in time?
6. How do I export all my data, in what format, and how long does it take?
7. When you deploy a new version, does every tenant get it at once? Can we be told in advance?
8. What happens to our data when we leave, and when is it deleted?

These are the questions we answer for our own products and the ones we design for when we build multi-tenant platforms for clients.

When does single-tenant make sense?

Sometimes. A very large hospital group with its own IT team, a government body with a data residency rule that names the building, or a customer whose auditors require dedicated infrastructure may need a separate deployment. It costs more, updates arrive later, and the customer takes on some of the operational work. For most businesses, a well-built multi-tenant product with clear answers to the questions above is safer than a private server nobody patches.

Frequently asked questions

Is multi-tenant less secure than a private server?

Not by itself. Security depends on how the isolation is built and tested, how access is controlled, and whether anyone is patching the servers. A shared platform run by a team that monitors it daily is usually safer than a private installation that was set up once and forgotten. Ask about the tests and the monitoring, not the model.

Can we have our own domain and branding on a multi-tenant product?

Usually, yes. Custom domains, logos, letterheads and colours are standard per-tenant settings on a well-built product. What you cannot usually have is a different workflow from every other tenant, because that is custom code, not configuration. If your workflow truly differs, that is a conversation about a custom build rather than a setting.

Will another tenant's heavy usage slow us down?

It can, if the vendor has not planned for it. Ask how they limit any one tenant's load, whether reports run on a separate database copy, and whether large tenants can be moved to their own resources. Slowdowns caused by neighbours are the most common practical complaint about shared platforms, and a good vendor has an answer ready.