Multi-Tenant Architecture: Row-Level Security vs Schema Isolation.

The multi-tenancy decision

Every SaaS platform needs to answer one fundamental question early: how do you isolate customer data? Get it right and you have a clean, scalable architecture. Get it wrong and you’re looking at a painful migration 12-18 months down the road — right when you should be focusing on growth. (Related: Stripe billing edge cases for SaaS.)

After building multi-tenant systems for 50+ clients, we’ve narrowed the decision to two viable patterns: row-level security (RLS) and schema isolation. Each has clear trade-offs, and the right choice depends on your compliance requirements, scale expectations, and team size.

Row-level security: shared tables, filtered access

With RLS, all tenants share the same database tables. Every row has a tenant_id column, and a database-level policy ensures queries only return data belonging to the authenticated tenant.

In PostgreSQL, this looks like setting a session variable at connection time and defining policies that filter on it. The application never constructs tenant-specific WHERE clauses — the database handles isolation transparently.

When RLS works well:

• You have hundreds or thousands of tenants with similar data volumes
• Schema changes need to roll out to all tenants simultaneously
• Cross-tenant analytics or reporting is a product feature
• Your team is small and can’t manage per-tenant infrastructure

The risks:

• A bug in your RLS policy means a data leak across all tenants
• Noisy neighbor problems — one tenant’s heavy query affects everyone
• Harder to provide per-tenant customization or data residency guarantees

Schema isolation: separate schemas, shared database

With schema isolation, each tenant gets their own database schema (or database) with identical table structures. The application routes connections based on the authenticated tenant.

When schema isolation works well:

• Enterprise clients require strong data isolation guarantees
• Compliance frameworks (SOC 2, HIPAA) mandate logical separation
• Tenants have very different data volumes (10 rows vs 10M rows)
• Per-tenant backup and restore is a product requirement

The risks:

• Schema migrations must run against every tenant — this gets slow at scale
• Connection pooling becomes complex (one pool per schema or a shared pool with schema switching)
• Operational overhead grows linearly with tenant count

Our recommendation

Start with RLS unless you have a compliance reason not to. It’s simpler to operate, simpler to deploy, and simpler to migrate away from if you outgrow it. The migration from RLS to schema isolation is well-understood; the reverse is painful.

If you’re building for healthcare, finance, or government — start with schema isolation. The compliance requirements will push you there anyway, and it’s better to start right than to migrate under pressure.