The three tenancy models
Every SaaS platform must make a fundamental choice about how it separates customer data. The three models represent a spectrum from operational simplicity to strict data isolation.
Shared database, shared schema
All tenants share a single database and schema. Every table has a tenant_id column, and all queries include a WHERE tenant_id = ? filter. This is the simplest model to build and operate — one database to manage, one schema to migrate, no per-tenant infrastructure.
The risks: a missing tenant_id filter in a query leaks data across tenants (a critical security risk that requires rigorous code review and testing to prevent), and a noisy neighbour (one tenant running expensive queries) can impact all others.
Shared database, separate schemas
All tenants share a database server, but each tenant has their own schema (in PostgreSQL, a schema is a namespace within a database). This provides data isolation at the schema level — a query in Tenant A's schema cannot accidentally access Tenant B's data — while sharing the database server's resources.
Migrations become more complex: instead of running one migration, you run it N times (once per tenant schema). This is manageable with proper migration tooling but requires discipline.
Separate databases
Each tenant has their own database. This provides the strongest isolation — a security incident affecting one tenant's database does not affect others, and one tenant's database performance does not impact others.
The operational overhead is significant: database provisioning, monitoring, backup, and migration must be automated for this model to scale.
Choosing the right model
Shared schema for most early-stage SaaS
If you are building a SaaS product and launching to your first 100 customers, start with the shared schema model. The operational simplicity is valuable when you are iterating quickly, and the data isolation risk can be managed with careful code review, automated testing, and a Row Level Security implementation (PostgreSQL RLS provides database-level enforcement of tenant isolation).
Schema-per-tenant for regulated industries
For SaaS products targeting regulated industries (healthcare, finance, legal), schema-per-tenant provides stronger audit trail capabilities and easier compliance demonstration. Each tenant's data can be exported, encrypted, or deleted independently without cross-tenant risk.
Database-per-tenant for enterprise and highest-value customers
For enterprise customers who require contractual data isolation guarantees or have specific data residency requirements (data must remain in a specific geographic region), database-per-tenant is sometimes the only compliant option.
Practical implementation patterns
Tenant resolution middleware
Every request to your application must resolve to a tenant before any data access occurs. Common tenant resolution patterns: subdomain (tenant.yourapp.com), path prefix (/org/tenant-slug/), header (X-Tenant-ID), or JWT claim.
Build tenant resolution as middleware that runs on every request and makes the tenant context available to all downstream handlers. Never allow a request to proceed without a resolved tenant.
Row Level Security in PostgreSQL
For shared-schema multi-tenancy, PostgreSQL's Row Level Security (RLS) provides a database-level enforcement layer on top of application-level filtering. Enable RLS policies on all tenant-data tables and set the application's database session to the current tenant ID at connection time. This prevents data leakage even if application-level filtering has a bug.
Tenant context in background jobs
Background jobs (report generation, data processing, notification sending) run outside the HTTP request context. Every background job must carry the tenant context through the queue and enforce tenant isolation when accessing data — it is easy to accidentally run a job without tenant context and process data across all tenants.