Every subscription product you use is almost certainly multi-tenant. It is worth understanding what that means, because it explains both why the software is affordable and what you should be asking about it.
The idea
One system, one set of servers, one codebase — serving thousands of customers, each seeing only their own data.
The alternative, single-tenant, gives each customer their own separate copy. That was the norm when software was installed on a server in your building, and it is why business software used to cost what it did.
Multi-tenancy is why a small firm can pay a modest monthly figure for something that would once have required its own server, its own installation and its own upgrade project.
How separation actually works
This is the part worth understanding, because it is where the risk lives.
In a multi-tenant system, your records and another customer's records typically sit in the same database tables, distinguished by an identifier saying which organisation each row belongs to.
Every single query the system makes must therefore filter on that identifier. Show me the invoices — for this organisation. Show me the user — belonging to this organisation.
Well-built systems enforce this centrally, so it cannot be forgotten. Poorly built systems rely on each developer remembering, which works until the day somebody does not, and then one customer sees another's data.
Multi-tenant separation is a software guarantee rather than a physical one. That is entirely acceptable — provided it is enforced in one place rather than in a thousand.
What you get from it
Cost. Infrastructure shared across thousands of customers is dramatically cheaper per customer.
Updates for everyone. A fix deployed once reaches every customer immediately. No upgrade projects, no version fragmentation, no customers stranded on a release from four years ago.
Faster security patching. A vulnerability is closed everywhere at once, which is a genuine and underrated benefit.
Elastic capacity. Busy periods are absorbed by shared infrastructure rather than requiring each customer to over-provision.
What you give up
Control over timing. Updates arrive when the supplier ships them. If a change alters a workflow your team depends on, you adapt.
Deep customisation. You get configuration, not modification. That is usually fine and occasionally a genuine constraint.
Shared fate. If the platform has an outage, everyone is out. A dedicated system fails independently, for better and worse.
Noisy neighbours. A very large customer running heavy reports can affect performance for others, though mature platforms manage this.
When single-tenant is genuinely warranted
Occasionally it is: strict regulatory requirements about data location or isolation; contractual obligations from your own customers; a need to control precisely when changes happen; or integration requirements that need direct database access.
Outside those, single-tenant usually means higher cost, slower fixes and a version that drifts behind. Businesses often ask for it out of instinct rather than requirement, and pay considerably for the reassurance.
Questions to ask a supplier
These get useful answers and take one email.
- How is one customer's data separated from another's, and where is that enforced? You want to hear that it is centralised, not that each developer is careful.
- Which country is the data stored in, and where are the backups? Backups in a different jurisdiction is a common and rarely disclosed detail.
- Who at your company can see my data, and is that access logged? Support staff usually can. That is normal; it should be controlled and recorded.
- What sub-processors are involved? Under UK GDPR you are entitled to know, and the list is often longer than expected.
- How do I export everything, in what format, and how long does it take? The answer tells you how trapped you would be. See avoiding vendor lock-in.
- Have you had a security incident, and what changed afterwards? A supplier who answers this candidly is usually a better bet than one who claims never to have had one.
If you are building rather than buying
Three things matter more than everything else.
Enforce separation in one place. Automatic scoping at the data layer, so an individual query cannot forget it.
Test it deliberately. Automated tests that attempt to read another organisation's records and assert failure. This is cheap and it catches the class of bug that ends companies.
Log access. Who read what, when. Both for investigation and because customers will ask — see why audit logging matters.
Our web applications team builds multi-tenant systems with separation enforced centrally and tested automatically. Start a conversation if you are evaluating a platform and would like help asking the right questions.
