Multi-tenant SaaS architecture explained for founders

In short: multi-tenant means one running application serves many customers (tenants) whose data must never mix. The decision that matters is how you isolate them: a tenant ID on every row, a schema per tenant, or a database per tenant. Most early SaaS products start with a tenant ID on every row, which is cheap and workable, and fails dangerously if even one query forgets the filter. Below is what that means for a founder who has to judge a vendor's estimate.

What multi-tenancy actually is

A single-tenant product serves one customer: one company, one set of data. A multi-tenant product serves many customers from the same codebase and infrastructure, each seeing only their own data, often with their own settings, roles and branding. A federation platform where each sports federation has its own clubs, licences and finances is multi-tenant. So is a garage-management product where each garage sees only its own clients and invoices.

The three isolation models

Model	How it works	Strength	Risk
Shared tables, tenant ID per row	Every table has a tenant column; every query filters on it	Cheapest to run, simplest to ship	One forgotten filter leaks data between customers
Schema per tenant	Same database, separate set of tables per tenant	Stronger separation, easier per-tenant restore	Migrations multiply with the number of tenants
Database per tenant	Each tenant has its own database	Strongest isolation, simple to export or delete a tenant	Highest cost and operational load

There is no universally right answer. The right one depends on the sensitivity of the data, the number of tenants you expect, and how much operational work you can carry.

What goes wrong in practice

On a multi-tenant SaaS for garages, an audit found and fixed 14 documented bugs. The most serious were cross-tenant data-leak risks: a query missing its tenant-ID filter could have exposed one garage's certificates to another (see the ToliMaster case study). That is the characteristic failure of the shared-tables model, and it is invisible in a demo with one customer.

The lesson is not to avoid the model. It is to design the isolation so a forgotten filter is hard to write: scope queries through a single data-access layer, add automated tests that try to read another tenant's records, and review every new endpoint for the tenant check.

Beyond data: what else is per tenant

• Identifiers. On a federation platform I built, each federation has its own sequential numbering (licence numbers, for example), so numbering has to be per tenant, not global. See SportIQ.
• Roles. The same platform has five roles per federation. Roles multiply screens and rules.
• Files. Uploaded documents need tenant-scoped access, not just tenant-scoped database rows. On that platform file access goes through a separately secured file service.
• Configuration and billing. Registration, suspension, plans and settings per tenant are a feature set of their own. Turning a single-tenant tool into a real multi-tenant product took a 6-phase, 60-task plan on the garage platform.

The estimate trap

A founder arrived with a vendor estimate of 45 days for a multi-tenant SaaS backend and wanted to know whether it was real. It was not: the estimate assumed a single-tenant data model, and the multi-tenancy the product needed had not been priced at all. The gap was about 25 developer-days, a little over $12,000 that would have surfaced as a change request halfway through. Ask every vendor one question in writing: how is tenant isolation implemented, and how is it tested?

Questions to ask before you commit

1. Which isolation model, and why that one for our data sensitivity?
2. How do you prove one tenant cannot read another's data?
3. How is numbering, configuration and file access scoped per tenant?
4. How would you export or delete one tenant's data on request?
5. What does adding the hundredth tenant cost, in effort and in infrastructure?

If you want a vendor's proposal checked before you sign, one prepared hour is enough: the Architecture Power Hour returns a one-page decision record. For a broader review of an existing codebase, see the Delivery Risk Audit and the technical due diligence checklist.