The foundation of SaaS architecture
Every SaaS founder wants their product to scale from ten users to ten thousand without requiring a complete rewrite. Achieving this requires a solid multi-tenant architecture designed from day one.
In a multi-tenant model, all customers (tenants) share the same application code and database server. The challenge is ensuring absolute data isolation: a user from Tenant A must never, under any circumstances, see data belonging to Tenant B.
Database isolation models
There are three main ways to isolate tenant data in a relational database like PostgreSQL:
1. Database-per-tenant (Physical isolation)
Each customer gets their own database. This is the most secure model and makes backups easy, but it is expensive to run and difficult to update. Modifying the schema means running migrations across thousands of separate databases.
2. Schema-per-tenant (Logical isolation)
All tenants share one database, but each gets their own namespace (schema). This is a solid middle ground, but it becomes slow when you reach hundreds of schemas due to connection pool overhead.
3. Shared database, shared table (Row-level isolation)
All tenants share the same tables. Each row has a tenant_id column. We enforce isolation using PostgreSQL Row-Level Security (RLS). This is the most scalable model and is what we recommend for modern B2B SaaS.
Implementing Row-Level Security (RLS)
RLS shifts the security responsibility from the application code to the database engine. If a developer forgets a WHERE tenant_id = X filter in their SQL query, RLS acts as a fail-safe.
Here is how you enable it in PostgreSQL:
-- Enable RLS on our customers table
ALTER TABLE customers ENABLE ROW LEVEL SECURITY;
-- Create a policy checking tenant association
CREATE POLICY tenant_isolation_policy ON customers
USING (tenant_id = current_setting('app.current_tenant_id'));
When a request arrives, our Next.js backend sets the local session variable app.current_tenant_id at the start of the transaction. PostgreSQL then filters all queries automatically.
Scalability bottlenecks to avoid
As your SaaS grows, watch out for these common bottlenecks:
- Shared connection pools — Ensure you use a connection pooler like PgBouncer to manage database connections.
- Heavy migrations — Keep migrations additive. Avoid dropping columns or restructuring tables in ways that require lockouts.
- Tenant-specific logic — Resist the temptation to write custom code for individual large clients. If a client needs a custom feature, build it as a configurable setting.