Multitenant SaaS Architecture: Row-Level vs Schema-Based Isolation
Choosing the wrong multitenancy strategy at the start of a SaaS build is the kind of technical debt that quietly compounds until a rewrite becomes unavoidable. Get it wrong and you are either leaking tenant data, paying for infrastructure you do not need, or spending weeks migrating schemas when a customer demands a dedicated environment. This is the decision framework that most tutorials skip.
What Multitenancy Actually Means
Multitenancy is the practice of serving multiple customers — tenants — from a single running application. The data, configuration, and often the business logic for every tenant lives in the same system. The question is never whether to isolate tenants; it is how deeply and at what layer.
There are three common strategies:
- Shared database, shared schema (row-level isolation) — all tenants share the same tables; a
tenant_idcolumn distinguishes rows. - Shared database, separate schemas — one database, but each tenant gets their own set of tables under a dedicated Postgres schema.
- Separate database per tenant — full database-level isolation, usually reserved for enterprise or regulated deployments.
This article focuses on the first two, because they are where most early-to-mid-stage SaaS products live — and where most architectural mistakes happen.
Row-Level Security: Simple Until It Is Not
Row-level security (RLS) in Postgres lets you attach policies directly to tables so that queries automatically filter by the current tenant context. A policy might look like this:
-- Enable RLS on the orders table
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
-- Policy: tenants can only see their own rows
CREATE POLICY tenant_isolation ON orders
USING (tenant_id = current_setting('app.current_tenant_id')::uuid);
You set app.current_tenant_id at the start of each database session — typically in your connection pool middleware — and Postgres enforces the filter on every query, automatically.
Why founders default to this
- One migration to rule them all. Adding a new feature means one
ALTER TABLE, not dozens of schema-level changes replicated across every tenant. - Lower infrastructure cost at low scale. You are not managing connection pools per schema or per tenant. One schema, one pool.
- ORM compatibility. Most ORMs (Django, Rails ActiveRecord, Prisma) handle a single-schema setup with minimal ceremony.
Where it breaks down
RLS is deceptively fragile under operational pressure. The most dangerous failure mode is the misconfigured session variable — if app.current_tenant_id is not set before a query executes, a permissive policy returns all rows, and a restrictive one returns none. Both are bugs; one is a data breach.
There is also an indexing burden. Every table needs a tenant_id column, every query needs that column in the index, and query planners can behave unexpectedly when tenant data is highly skewed — a tenant with 2 million rows sharing a table with tenants averaging 500 rows will cause index bloat and slow plan selection for everyone.
Best suited for: Products below 500 tenants, early product-market fit stages, or internal tools where tenants are departments rather than paying customers.
Schema-Per-Tenant: More Control, More Ops
In Postgres, a schema is a namespace within a database. Schema-per-tenant means every customer gets tables like tenant_acme.orders and tenant_beta.orders — identical in structure, completely separate in storage.
You route queries by setting the search_path at the session level:
SET search_path TO tenant_acme, public;
From that point, SELECT * FROM orders hits only tenant_acme.orders. No policy enforcement needed; the namespace itself provides the isolation.
Why this scales better operationally
- Tenant-specific migrations. Need to roll out a schema change to one enterprise customer ahead of others? You can. Row-level setups make this nearly impossible without feature flags layered on top.
- Cleaner backups and restores. Restoring a single tenant's data from a schema dump is far simpler than filtering rows from a shared table.
- Noisy neighbour mitigation. A runaway tenant query still hits shared compute, but the data access patterns are scoped, making it easier to observe and throttle per tenant.
The real costs
Schema-per-tenant introduces migration complexity that grows linearly with your tenant count. At 50 tenants, running ALTER TABLE across every schema is manageable. At 5,000 tenants, you need a migration orchestration layer — essentially, a background job system that tracks schema versions per tenant and applies changes in batches.
Connection pooling also becomes more complex. Postgres connections are not free, and if you are switching search_path per request on PgBouncer in transaction-pooling mode, you will hit subtle bugs where the search path leaks between transactions.
Best suited for: B2B SaaS products with 50–5,000 tenants, compliance-sensitive verticals (fintech, healthtech), or products where tenant customisation — custom columns, per-tenant extensions — is part of the value proposition.
A Decision Framework by Growth Stage
| Stage | Tenant Count | Recommended Strategy | Key Concern |
|---|---|---|---|
| Pre-launch / MVP | 0–50 | Row-level (RLS) | Speed of iteration |
| Early growth | 50–500 | Row-level with audit hardening | Data leak risk |
| Scale | 500–5,000 | Schema-per-tenant | Migration ops, compliance |
| Enterprise | 5,000+ | Schema or DB-per-tenant | SLA, data residency |
The transition from row-level to schema-per-tenant is painful but not catastrophic if you plan for it. The key is to build your tenant resolution layer — the code that sets tenant context on every request — as a distinct, swappable module from day one. Switching the underlying isolation strategy then becomes a data migration problem, not a re-architecture of your entire codebase.
The Hybrid Approach Worth Considering
A pattern gaining traction among mid-stage SaaS companies is a tiered isolation model: standard customers sit in a shared-schema pool with RLS enforced, while enterprise or high-value customers get dedicated schemas — or even dedicated databases — provisioned automatically at contract signing.
This matches commercial reality. Most African SaaS founders are selling to a mix of SMEs on monthly plans and large corporates on annual contracts with data sovereignty requirements. Your architecture should reflect that pricing tier, not fight it.
The provisioning logic is not trivial — you need a tenant registry, an onboarding service that creates schemas on demand, and a routing layer that knows where to point each request — but the commercial upside of being able to offer "dedicated infrastructure" as an enterprise upgrade is significant.
Why This Matters for Your Project
The multitenancy decision shapes your database design, your DevOps runbook, your compliance posture, and your pricing model. Getting it right early — or at least making the choice consciously rather than by default — is the difference between a codebase that scales with your revenue and one that forces a rewrite at the worst possible moment. If you are building a SaaS product and want a second opinion on your data architecture before you commit, this is exactly the kind of decision worth getting right at the design stage.
