If you’re building a SaaS product, the way you isolate tenant data is one of the
few architectural decisions that gets genuinely expensive to reverse once you have
paying customers. Get it right early and you barely think about it again. Get it
wrong and you end up migrating live customer data between isolation models while
also trying to ship features — a project nobody enjoys.
This is for founders and technical leads who are past the “will anyone pay for
this” stage and into “how do we actually build this so it doesn’t fall over at 200
customers”. We’ll walk through the three common ways to isolate tenant data, where
each one breaks down, and a pragmatic way to choose without over-engineering for
scale you don’t have yet.
Why this decision matters more than it looks
Multi-tenancy sounds like a database problem, but it’s really a risk-management
problem. Get the isolation model wrong and the failure mode isn’t “the app is slow”
— it’s “tenant A can see tenant B’s data”, which is the fastest way to lose a
customer, fail a security review, or breach a contract. At the same time,
over-isolating too early (a separate database per customer when you have twelve
users) adds operational overhead that slows you down for no real benefit.
The right answer depends on three things: how many tenants you expect, what your
compliance and contractual obligations look like, and how big your team is to
operate whatever you build. Worth settling before you write your first migration,
not after.
The three common isolation models
Shared schema, shared tables (the pooled model)
Every tenant’s rows live in the same tables, distinguished by a tenant_id
column. This is the default starting point for most SaaS products, and for good
reason: one database to operate, one set of migrations to run, and it scales into
the thousands of tenants without much operational drama. Backups, monitoring and
schema changes all happen once, not per tenant.
The catch is that isolation lives entirely in application logic and query
discipline, unless you enforce it at the database layer. Miss a WHERE
tenant_id = ? clause in one query, in one code path, once, and you have a data
leak. In Postgres this is exactly what Row-Level Security (RLS) is for: you attach
a policy to each table that filters rows by the current tenant automatically, so
even a forgotten filter in application code can’t return another tenant’s data.
It’s not free — every table needs a policy, and a missed one is a silent gap — but
paired with automated tests that assert cross-tenant queries return nothing, it’s
a solid default.
Schema-per-tenant
Each tenant gets their own schema within the same database instance, with the
same set of tables duplicated per schema. This gives you real structural
separation — a bug in a query can’t accidentally cross into another tenant’s
schema the way it can with a missing filter in a shared table — and it makes
per-tenant customisation (a tenant-specific field, a different retention policy)
easier to reason about.
The cost shows up operationally. A migration now has to run against every
schema, not once. Cross-tenant analytics or admin dashboards mean either union
queries across dozens or hundreds of schemas, or a separate reporting pipeline
that aggregates data out. And most database engines start to strain once you’re
managing schema or table counts in the thousands — connection pooling and
catalog metadata weren’t designed for that. This model tends to suit products
with a moderate, fairly stable tenant count and real per-tenant configuration
needs, rather than a self-serve product signing up hundreds of tenants a week.
Database-per-tenant
The strongest isolation: each tenant gets an entirely separate database,
sometimes on separate infrastructure. This is usually driven by something outside
pure engineering preference — a healthcare or financial customer’s compliance
team requiring physically separate storage, a data residency requirement that
means an EU customer’s data can’t sit in the same instance as a US customer’s, or
a contract that explicitly demands it.
It’s the most expensive model to operate: provisioning, migrations, backups and
monitoring all multiply by tenant count, and you’ll need real automation around
tenant provisioning before this is sustainable past a handful of customers. Very
few products need this for every tenant. Plenty need it for a specific enterprise
tier.
Deciding without over-engineering
A few questions cut through most of the debate:
- How many tenants, realistically, in two years? Tens or low
hundreds can justify schema-per-tenant. Thousands, and you almost certainly want
the pooled model with RLS. - Do any customers have hard isolation requirements? A
contract clause or a compliance framework that demands separate storage is a
business requirement, not a technical preference — it overrides whatever’s
operationally convenient. - Who operates this day to day? A two-person engineering team
will struggle to keep hundreds of tenant schemas migrated and healthy. A pooled
model with strong tests is far more forgiving of a small team. - Does pricing or product strategy already segment tenants into
tiers? If it does, you don’t have to pick one model for everyone. A
common, sensible pattern is pooled tables with RLS for most customers, and a
dedicated database reserved for an enterprise tier that specifically pays for
it.
That hybrid approach is worth calling out on its own, because it’s often the
right answer and rarely the first one teams consider. You don’t need to solve
isolation once for every customer segment — you need a default that’s cheap to
operate at volume, and an escape hatch for the handful of tenants who need more.
Mistakes that cause real pain later
A few patterns show up repeatedly in products that struggle with this:
- Isolation enforced only in application code, with no database-level
backstop. Every query relies on a developer remembering to filter by
tenant. It works until it doesn’t, usually in a rushed feature or a background
job that was written differently to the rest of the codebase. - No automated test that actively tries to leak data across
tenants. If you have RLS or tenant-scoped queries, write a test suite
that logs in as tenant A and asserts it cannot read tenant B’s data, and run it
on every change. This is one of the highest-value tests you can own. - A single noisy tenant degrading everyone else. Pooled
tables mean pooled resources. One tenant running a heavy report or bulk import
can slow the database for everyone unless you’ve thought about indexing, query
timeouts and, eventually, workload isolation for your busiest accounts. - Retrofitting isolation after a compliance requirement lands.
Migrating a live tenant from shared tables into its own database, with zero
downtime and no data loss, is a genuinely hard project. Deciding in advance
which tier of customer might need that, and designing the escape hatch before
you need it, is far cheaper than doing it under contractual pressure.
A pragmatic starting point
For most early and growth-stage SaaS products, the sensible default is: shared
tables, a tenant_id on every row, Row-Level Security policies enforcing
that boundary at the database layer, and an automated test suite that tries to
break it on every deploy. Keep the data model clean enough that pulling a
high-value tenant out into its own database later is a plumbing problem, not a
rewrite. That’s the model we reach for by default when we’re helping teams design
the data layer for a new product — not because it’s the most sophisticated
option, but because it’s the one that scales with a small team and doesn’t cost
you anything you don’t already need.
The isolation model you choose on day one doesn’t need to be the one you run
forever. It just needs to be one you can defend to a security-conscious customer,
operate with the team you actually have, and change later without a
migration project nobody signed up for.
If you’re scoping a new SaaS product and want a second opinion on the data
architecture before you commit to it, book a
free consultation — it’s a much cheaper conversation to have now than after
your first enterprise customer asks about data residency.
Related: Data Protection by Design: A Practical Engineering Guide — your isolation model is only one part of the picture; this guide covers the wider architectural decisions that keep tenant data GDPR compliant by design.
