Deconstructing SaaS Multi-Tenancy: Row-Level Security vs Isolated Databases
Daniel Okafor
· Principal Architect
Updated: 2025-09-28
9 min read
When building a B2B SaaS, data isolation is critical. We explore the architectural trade-offs between shared tables with RLS and schema-per-tenant designs.
Summary Key Takeaways
- Shared schema with Postgres RLS is the right default for most B2B SaaS companies.
- Schema-per-tenant offers stronger isolation at the cost of operational complexity.
- Database-per-tenant is justified only for large, regulated, or high-touch customers.
- Tenant isolation is a commercial decision as much as a technical one.
Introduction
Multi-tenancy is the foundation of every B2B SaaS. It dictates how you isolate customer data, how you scale operations, and how you comply with regional regulations. Choosing the right isolation strategy early is a multiplier on long-term velocity.
We typically see three patterns: shared schema with row-level security (RLS), schema-per-tenant, and database-per-tenant. Each has different operational and security trade-offs.
Shared Schema with Row-Level Security
Postgres RLS is mature, performant, and dramatically simplifies operations. A single database, a single migration pipeline, and tenant context enforced at the database layer. The trade-off is that a bug in the RLS policy is a multi-tenant breach.
Schema-Per-Tenant
Stronger logical isolation, easier per-tenant backups, and easier compliance audits. The cost is operational complexity: migrations become per-tenant, and observability requires per-schema tooling.
Database-Per-Tenant
The strongest isolation. Required for some regulated workloads. But it is operationally expensive and only pays off when individual tenants are large or have strict data residency requirements.
Decision Matrix
Most B2B SaaS companies should default to shared schema with RLS until they hit a tenant size, regulatory requirement, or commercial tier that justifies a stronger isolation model. The migration path from RLS to schema-per-tenant is well-trodden, so the upfront simplicity is rarely wasted.
Conclusion
Tenant isolation is a product decision, not just a database one. Anchor the choice in your commercial tiers, regulatory exposure, and operational maturity, not in architectural aesthetics.
References & Citations
Designing a Multi-Tenant SaaS?
We help founders design and validate a tenant isolation strategy aligned with their commercial tiers and regulatory exposure.
Frequently Asked Questions
What is the best multi-tenant strategy for SaaS?
Most B2B SaaS companies should start with a shared schema using Postgres Row-Level Security. It minimizes operational overhead and scales to thousands of tenants.
Is Postgres RLS production-ready?
Yes. Postgres RLS has been production-ready for years and is used at scale by companies like Supabase, Notion, and many others.
When should I switch from shared schema to schema-per-tenant?
Switch when an enterprise customer requires dedicated backups, regulatory isolation, or a contractual data residency commitment.
Designing a Multi-Tenant SaaS?
We help founders design and validate a tenant isolation strategy aligned with their commercial tiers and regulatory exposure.
Already Have a Multi-Tenant Stack?
Share your current isolation strategy. We will review the policies and recommend targeted hardening.