Multi-Tenant

Multi-tenant architecture is the dominant SaaS infrastructure pattern in which a single instance of an application — and typically a single database — serves many separate customers ("tenants," e.g., different companies), with each tenant's data kept logically isolated from every other tenant's, even though they physically share the same underlying compute and storage. This is the opposite of a single-tenant architecture, where each customer gets a fully separate, dedicated instance and database. Multi-tenancy is what makes SaaS economically viable at scale: instead of provisioning and maintaining a separate server and database per customer (single-tenant), a vendor deploys one codebase and one set of infrastructure that serves thousands or millions of customers simultaneously, dramatically reducing per-customer operational cost and letting every customer benefit instantly from the same bug fixes and feature releases. There are three common implementation strategies, in increasing order of isolation (and cost): (1) shared schema with a `tenant_id` column on every table, filtered via application-level row-level security or middleware on every query — cheapest, most common for early-stage SaaS; (2) shared database, separate schema per tenant — moderate isolation, easier per-tenant backup/restore; (3) fully separate database per tenant — highest isolation and easiest to satisfy strict compliance/data-residency requirements, but reintroduces much of single-tenant's operational cost. The single most catastrophic bug class in multi-tenant systems is a tenant-isolation failure — a query missing its `WHERE tenant_id = ?` filter that leaks Tenant A's data to Tenant B — which is why mature multi-tenant SaaS codebases enforce isolation at the database or ORM layer (e.g., Postgres Row-Level Security policies) rather than trusting every application query to remember the filter. Concrete worked example: a project management SaaS uses a shared Postgres database where every table (`projects`, `tasks`, `comments`) includes a `tenant_id` foreign key. A Postgres RLS policy is defined as `CREATE POLICY tenant_isolation ON tasks USING (tenant_id = current_setting('app.tenant_id')::uuid);` — meaning even if an application-layer bug forgets to filter by tenant in a query, the database itself refuses to return rows belonging to a different tenant, providing defense-in-depth against the single most damaging category of SaaS security bug. Some SaaS products offer a hybrid "silo" tier for their largest or most compliance-sensitive customers — a fully dedicated database (or even dedicated compute) provisioned within an otherwise multi-tenant platform, giving that specific customer stronger isolation guarantees and easier data-residency compliance without the vendor having to abandon multi-tenancy as its default, cost-efficient architecture for everyone else.