Multi-tenant SaaS in plain English: what it means when one app serves many businesses

"Multi-tenant" sounds like a technical detail that only matters to engineers. In practice, it's the architecture behind most of the business software you use without thinking about it.

The basic idea

A multi-tenant application runs one codebase, one infrastructure, serving many separate businesses ("tenants") at once — each with their own data, users and (often) their own subdomain or custom domain, while sharing the same underlying application. Your project management tool, your e-commerce platform, your booking system — if it's something you signed up for rather than installed, it's very likely multi-tenant.

The alternative, and why it's usually worse for everyone

The opposite approach — a separate, fully isolated install per customer — means every bug fix, security patch and new feature has to be deployed individually, business by business. That doesn't scale past a handful of customers without a dedicated team just managing deployments. Multi-tenancy is what makes it possible to improve the product once and have every customer benefit immediately.

How tenant data actually stays separate

There are a few common approaches, in increasing order of isolation:

• Shared database, tenant ID on every row — simplest to build, requires careful, consistent filtering everywhere to avoid ever leaking one tenant's data into another's view.
• Separate database per tenant, same app code — stronger isolation, since a bug in a query literally can't reach another tenant's database; more operational overhead to manage many databases.
• Subdomain or custom domain per tenant — business-name.platform.com or their own connected domain, routed by the app to the right tenant's data and branding.

Why this matters even if you never build one

If you've ever wondered how a single SaaS product can offer your business "your own branded portal" with your own domain and users, while clearly running the exact same software as every other customer — that's multi-tenancy doing its job invisibly. The good ones make isolation and customization feel automatic; the underlying engineering to get there is genuinely non-trivial.

Where this shows up in our own work

Building multi-tenant platforms (subdomains, per-tenant databases, subscription billing per tenant) is part of what our backend team does for clients who want to launch a SaaS product rather than a single-customer app. It's a different set of problems than a typical web app — billing, data isolation, and onboarding all need to work per-tenant from day one, not bolted on after launch.

Once you know what to look for, you'll start noticing multi-tenant architecture behind a surprising share of the business software you already use.