Ampity Infotech

Multi-Tenant Architecture

Key Takeaways

  • 1. Shared database with RLS: Best for fewer than 500 tenants, lowest cost.
  • 2. Separate schemas: Sweet spot for 500-5000 tenants.
  • 3. Dedicated databases: For enterprise clients, compliance requirements.
  • 4. Real cost analysis from 40+ production platforms.

The Three Patterns

After building multi-tenant systems for 112+ SaaS platforms, we’ve seen these three patterns emerge as the most practical choices. Each has distinct tradeoffs in cost, complexity, and isolation.

1. Shared Database with RLS (Row-Level Security)

Best for: Startups, B2B SaaS with fewer than 500 tenants

All tenants share the same database and tables. Tenant isolation is enforced through Row-Level Security policies that filter data based on tenant_id.

CREATE POLICY tenant_isolation ON orders USING (tenant_id = current_setting(‘app.tenant_id’)::uuid);

Pros: Simplest to implement, lowest infrastructure cost, easiest to maintain.
Cons:Limited customization per tenant, potential noisy neighbor issues.
Real cost:$200-500/month for 100 active tenants (AWS RDS, 3-5M queries/month)

2. Separate Schema Per Tenant

Best for: Growing SaaS companies, 500-5000 tenants

Each tenant gets their own PostgreSQL schema within a shared database instance. Better isolation while sharing infrastructure.

CREATE SCHEMA tenant_acme_corp;
SET search_path TO tenant_acme_corp;

Pros: Better isolation, per-tenant customization possible, shared connection pooling
Cons: Schema migrations more complex, connection routing overhead
Real cost: $800-2000/month for 1000 active tenants

3. Dedicated Database Per Tenant

Best for: Enterprise clients, regulated industries (HIPAA, SOC 2)

Each tenant gets their own dedicated database instance. Maximum isolation and customization.

  • Pros:Complete isolation, per-tenant scaling, compliance-friendly
  • Cons:Highest operational cost, complex migrations, infrastructure overhead
  • Real cost:$150-500/month per enterprise tenant

Decision Framework

Start with RLS if: You’re pre-product-market-fit, building an MVP, or targeting SMB customers.
Move to schemas when: You pass 500 tenants, need tenant-specific customizations, or face noisy neighbor issues.
Go dedicated when: Selling to enterprises, compliance requires it, or tenants want dedicated capacity

Common Pitfalls


1. Over-engineering early: Don’t start with dedicated databases unless compliance requires it. Most SaaS companies successfully run 1000+ tenants on shared infrastructure.
2. Ignoring connection pooling: Schema-per-tenant requires careful connection pool management. Use PgBouncer.
3. Missing tenant context: Always set tenant context at the connection level, not in application queries. Prevents data leaks.