How does multi-tenancy work?
A multi-tenant application attaches a tenant identifier to every request and every record. When a user signs in, the app resolves which tenant they belong to, then scopes every query, background job, and message to that tenant. All tenants run on the same servers and usually the same database, which keeps the operating cost per tenant low — but the isolation is only as strong as the code and database constraints that enforce it.
What are the main isolation models?
| Isolation model | How it works | Trade-off |
|---|---|---|
| Shared database, tenant key | Every row carries a tenant ID; every query filters on it | Cheapest to run; one missed filter can leak data across tenants |
| Schema per tenant | Each tenant gets its own schema inside a shared database | Stronger separation; migrations multiply with tenant count |
| Database per tenant | Each tenant gets a dedicated database or instance | Strongest isolation; highest cost and operational overhead |
Why does multi-tenancy matter for a small team?
If you run one product under one brand, tenancy may never cross your mind. It matters the moment you serve several brands, client workspaces, or environments from one install — the common case for agencies and small platforms. Open-source engagement tools such as Dittofeed model tenancy as workspaces, and a self-hosted customer engagement setup makes the whole install your own tenant boundary: your customers' data shares infrastructure with no one outside your company.
What does multi-tenancy change for compliance?
In a shared SaaS you are one tenant among thousands, relying on the vendor's isolation, data residency choices, and contracts. Self-hosting inverts that: you become the operator, so per-tenant isolation, retention, and the audit log are yours to configure — and to prove. Neither model is compliant by nature; GDPR obligations follow the data, not the architecture.