What Is Multi-Tenant SaaS, and When Does It Make Sense?

In a multi-tenant product, one application and one codebase serve every customer. Each customer is a tenant. A tenant might be a school, a clinic chain or a distributor.

Tenants share the running software, but not their data. A user from one tenant must never see a record from another. The software enforces this on every request.

Compare this with a flat building. Residents share the structure, the lift and the water tank. Each flat has its own lock.

Some things are common to all tenants, and they are the reason this model costs less to run than a separate installation for each customer. The code, the servers and the release schedule are shared. A fix is made once and reaches everyone.

Other things belong to one tenant alone. Data, users, settings, branding and plan limits are kept apart. Each tenant also has its own administrator, who manages that tenant’s users.

Isolation can be built in different ways, and the choice you make early will shape cost, backup routines and the effort of every later feature. Rows in a shared database can carry a tenant identifier. Or each tenant can have its own database schema. The choice affects cost, backup and how easily one tenant’s data can be exported.

The strongest sign is a large number of similar customers who all want broadly the same workflow from the product. If most of them want the same workflow with small differences, one platform serves them well. Differences are handled by settings, not by new code.

Subscription pricing is another sign. Plans, trials and renewals are easier when every customer lives in one system. Support also improves, because the team sees one version of the product.

Self-service signup points the same way. A new customer should be able to start without anyone installing anything.

Some customers cannot share. A large buyer may require its own server, its own region or its own release date. Contracts in some sectors say where data may be stored.

Heavy customisation is a second warning. If every customer needs different screens and rules, the shared code fills with exceptions. Each exception is a risk for every other tenant.

A product with two or three large customers is often better served by separate deployments. That choice can be revisited later.

Take a software product for tuition centres. Hundreds of centres want batches, fees and attendance. Each centre needs its own data, logo and fee rules. This is a natural multi-tenant product.

Now take a system for three hospital groups, each with its own integrations and hosting rules. Separate deployments may be simpler. The right answer depends on the customers, not on fashion.

Before building, decide the tenant boundary. Write down who a tenant is, what they own, and what happens when one leaves. Adding this later means touching every table and every query.