The tenancy model you pick in month one shapes your database design, your security posture, and your ability to scale for the next five years. Here's how to choose wisely.
Multi-tenancy is the architectural foundation that makes SaaS economically viable: one deployment, one codebase, many customers. But the way you implement isolation between those customers has consequences that compound over years. The teams that get it right in the early stages avoid expensive migrations later. The teams that pick the convenient shortcut tend to find themselves mid-series-B, unable to sign an enterprise deal because they can't offer the data isolation guarantee the procurement team is asking for. Understanding the three main tenancy models — and when each is right — is one of the most important architectural decisions a SaaS product makes.
The Three Tenancy Models
Shared Database, Shared Schema
All tenants share the same database tables, distinguished by a tenant_id column. This is the simplest model to implement and the cheapest to operate — one database, no per-tenant provisioning, minimal overhead. It scales well for high tenant counts at lower per-tenant data volumes. The tradeoff is isolation: a query without a tenant_id filter exposes data across tenants, and there's no database-level boundary between them. Security depends entirely on application-layer enforcement, which is reliable if your codebase is disciplined, but failure modes are catastrophic. This model is appropriate for B2C SaaS and lower-tier SMB products where regulatory data isolation requirements are limited.
Shared Database, Separate Schemas
Each tenant gets their own schema within a shared database. Tables are duplicated per schema (public.users vs tenant_a.users), and schema-level access controls provide a meaningful isolation boundary at the database level. This is significantly stronger than shared-schema isolation — a SQL injection or ORM misconfiguration in tenant A's queries cannot reach tenant B's schema. The cost is operational complexity: schema migrations must be applied across all tenant schemas, and provisioning a new tenant means creating a schema. PostgreSQL handles this model well; MySQL less cleanly. This is the right choice for mid-market B2B SaaS where customers expect reasonable data separation but don't demand full database-level isolation.
Separate Database Per Tenant
Each tenant gets a dedicated database instance. This is the gold standard for data isolation and is often required by enterprise customers, regulated industries (healthcare, finance, legal), and customers subject to data residency requirements. A database failure for one tenant doesn't affect others. You can offer per-tenant database backups, restore points, and geographic placement. The tradeoff is cost and operational overhead: each tenant carries the overhead of its own database, connection pooling, monitoring, and backup schedule. At small tenant counts this is manageable; at hundreds of tenants it requires significant automation. Reserved for enterprise-tier offerings and regulated verticals.
A common migration path: start with shared schema, move high-value or enterprise tenants to separate schemas or databases as they grow and as their requirements evolve. Design your application layer to support tenant-level database configuration from the start, even if everyone starts on shared schema — it's much harder to retrofit.
Authentication and Data Isolation
Regardless of tenancy model, every query in your application must be scoped to the authenticated tenant. The most robust pattern is a request-scoped tenant context that is set once at authentication and injected throughout the request lifecycle — into database queries, cache keys, file storage paths, and background job parameters. Never rely on the caller passing a tenant_id — derive it from the authenticated session. Middleware that sets this context and query builders that enforce it are your primary defence against cross-tenant data leakage.
Tenant-Aware Background Jobs
- 1Every background job must carry a tenant context parameter — queue it at dispatch time, not resolved at execution time
- 2Use separate job queues per tenant tier if job SLAs differ — a background task for an enterprise tenant should not queue behind bulk jobs from free-tier tenants
- 3Test for tenant context leakage in jobs explicitly — it's easy to miss a database query in a job that omits the tenant scope because jobs don't have a request lifecycle
- 4For multi-tenant batch operations (e.g. nightly invoicing), process one tenant at a time and scope all intermediate state to that tenant before moving to the next
- 5Log tenant context with every job for debugging — "job failed" without knowing which tenant it failed for is useless in production
Tenant Onboarding and Provisioning Design
Tenant provisioning should be fully automated from day one, even when you only have five customers. The work of creating a tenant — schema setup, seed data, default configuration, role assignment, notification setup — should be a single idempotent operation that takes seconds and never requires a developer to touch production manually. This matters for several reasons: it enforces consistent tenant state, it makes your onboarding experience reliable and fast, and it forces you to codify exactly what a tenant's initial state should look like — clarity you'll need when debugging tenant-specific issues later.
Data isolation issues in multi-tenant SaaS are almost always found in edge cases: bulk operations that iterate over all records without tenant scoping, analytics queries written without tenant filters, or background jobs that load configuration from a shared cache without tenant context. Test these paths specifically — they don't show up in standard feature testing.
Real-World Tradeoffs That Surprise People
- Schema migrations become expensive at scale — running ALTER TABLE on 500 tenant schemas is a maintenance window, not a deployment step; design schemas with this in mind from the start
- Tenant-specific customisation is harder than it looks — per-tenant feature flags, field customisation, and workflow configuration add significant complexity; define boundaries early
- Performance isolation degrades with noisy neighbours in shared models — one tenant with an inefficient query can impact all others; query timeouts and per-tenant rate limits help
- Database connection counts grow fast with per-tenant databases — connection pooling at the application layer is mandatory; PgBouncer is not optional at any meaningful scale
- Compliance certifications (SOC 2, HIPAA, ISO 27001) treat multi-tenancy rigorously — your isolation model will be examined; shared-schema models require more documentation and controls to pass
