Multi-Tenant Database Strategies

Complete decision tree for shared DB, separate schemas, or separate databases. Includes production metrics from 112+ platforms.

Quick Answer

• For 0-1K tenants: Shared DB + Row-Level Security
• For 1K-10K tenants: Shared DB + Separate Schemas
• For 10K+ tenants: Separate Databases per tenant

The Three Strategies Explained

Strategy 1: Shared Database + Row-Level Security

All tenants share the same database and tables. PostgreSQL Row-Level Security (RLS) ensures data isolation at the database level.

When to use:

• • 0-1,000 tenants with predictable growth
• • Need strong isolation guarantees for compliance
• • Healthcare, finance, or other regulated industries
• • Small to medium data per tenant (under 1GB each)

Healthcare SaaS platform with 500 clinics, 50K total patients. HIPAA compliant with complete audit trails.

Implementation

PostgreSQL

-- Create RLS policy
CREATE POLICY tenant_isolation ON patients
USING (
  tenant_id = current_setting('app.tenant_id')::uuid
);

-- Enable RLS on table
ALTER TABLE patients ENABLE ROW LEVEL SECURITY;

-- Set tenant context in application
SET app.tenant_id = 'clinic-uuid-here';

What breaks at scale:

• Connection pool exhaustion around 1,000 tenants
• Backup/restore becomes slow (all tenants affected)
• Query performance degrades without careful indexing
• One tenant’s heavy queries can impact all others

Production Metrics

Based on 15 implementations of the shared database pattern:

Metric	100 Tenants	500 Tenants	1,000 Tenants
DB Cost/month	$800	$2,500	$4,800
Avg Query Time	8ms	12ms	18ms
Backup Duration	5min	15min	35min
Support Incidents/mo	0-1	2-3	5-8