Software Growth

Multi-tenancy

Multi-tenancy means one running copy of your software serves many customers at once, each with their own isolated data and settings.

In a multi-tenant system, every customer (a tenant) shares the same application and infrastructure, but sees only their own data. Microsoft's architecture guidance puts it simply: a multitenant solution is used by multiple customers, or tenants, and a tenant is distinct from a user, since many users from one company form one tenant.

Nearly every small SaaS is multi-tenant, usually without anyone calling it that. If your database has an account_id column and every query filters on it, you are doing multi-tenancy.

Ways to isolate tenants

  • Shared everything. One database, one schema, a tenant ID on each row. Cheapest and easiest to run. The risk is a missed filter leaking one customer's data to another.
  • Schema per tenant. One database, a separate schema for each customer. Stronger separation, more migration work.
  • Database per tenant. Each customer gets their own database but shares the app servers. Easier backups and per-customer restores, higher cost.
  • Fully dedicated. Separate infrastructure per customer. This is single-tenant, covered on its own page.

Many companies mix these: shared for the long tail, dedicated for the few big accounts that pay for it.

Why it matters to the business

Multi-tenancy is what makes SaaS margins work. One deploy updates every customer, one set of servers carries all of them, and support looks at one version of the product. Your gross margin improves because infrastructure cost per customer falls as you add more. A founder with 300 customers on one stack can run it alone. The same founder with 300 separate installs cannot.

Where it bites

  • Noisy neighbors. One customer's huge import slows everyone. You need rate limits and queues.
  • Data leaks. Enterprise buyers ask how you isolate tenants in security questionnaires. Have a clear answer, and tests that prove it.
  • Per-customer demands. Custom data residency, a private region or a custom release schedule are hard to give from a shared stack.
  • Access control. Within a tenant you still need roles and permissions.

When a small SaaS should care

Start shared and put the tenant ID in the data model from the first commit. Retrofitting it is painful. Decide early where tenant filtering lives (a middleware or database row-level security rather than in each query), because that choice removes most leak bugs. Revisit isolation only when a large customer makes it a condition of the deal.

Related terms

Sources

Back to the SaaS glossary