what should I use for multi-tenant SaaS infrastructure

For a multi-tenant SaaS, the “best” infrastructure depends mostly on:

• Tenant count
• Data isolation requirements
• Scale/throughput
• Compliance needs (SOC 2, HIPAA, GDPR, etc.)
• How much operational complexity you can tolerate

Common architecture choices

1) Single shared app + shared database

Best for: early-stage SaaS, lots of small tenants
How it works: one app serves all tenants; tenant_id is used everywhere in the DB

Pros

• Cheapest and simplest
• Easy to operate
• Fast to ship

Cons

• Harder isolation
• Risk of noisy-neighbor issues
• Tenant-specific backups/restores are harder

Typical use

• Postgres + row-level tenant scoping
• Strong indexing on tenant_id
• Optional PostgreSQL Row Level Security (RLS)

---

2) Shared app + separate schema per tenant

Best for: moderate isolation needs
Pros

• Better isolation than shared tables
• Easier per-tenant export/restore than fully shared DB
• Still manageable cost

Cons

• Operationally more complex
• Migrations become harder across many schemas
• Some ORMs/tooling struggle

---

3) Shared app + separate database per tenant

Best for: larger customers, enterprise, compliance-heavy workloads
Pros

• Strong isolation
• Easier per-tenant scaling, backup, restore, and data residency
• Good for premium enterprise tiers

Cons

• More expensive
• More ops overhead
• Harder to manage at high tenant counts unless automated

---

4) Hybrid model

Best for: most SaaS companies at scale
Example:

• SMB tenants on shared DB
• Enterprise tenants on dedicated DB
• Optional dedicated infrastructure for top customers

This is often the best long-term answer.

---

My default recommendation

If you’re building a typical SaaS product, start with:

• One application
• PostgreSQL
• Shared database with strict tenant isolation
• Tenant-aware authorization in every query
• Row Level Security if possible
• Redis for caching/queues if needed
• Object storage like S3 for files
• Kubernetes only if you truly need it; otherwise use managed app hosting

This gives you:

• low cost
• simplicity
• room to grow

---

Infrastructure stack suggestions

Simple, modern stack

• App hosting: AWS ECS/Fargate, Fly.io, Render, or similar
• Database: managed PostgreSQL (RDS, Cloud SQL, Neon, Supabase, etc.)
• Cache/queue: Redis
• Storage: S3-compatible object storage
• Auth: Auth0, Clerk, Cognito, or custom
• Observability: Datadog, OpenTelemetry, Grafana, Sentry

If you expect enterprise customers

Add:

• Dedicated database options
• Audit logs
• Encryption key management per tenant
• Data export/delete tooling
• Region isolation
• Per-tenant rate limiting and quotas

---

Important design principles

• Enforce tenant isolation in the database and app layer
• Never trust only frontend tenant selection
• Make every entity tenant-scoped unless explicitly global
• Build migration and backup strategy early
• Plan for noisy-neighbor controls
• Add audit logs from day one if possible

---

Practical rule of thumb

• < 100 tenants: shared DB is usually fine
• 100s to 1000s of tenants: shared DB or hybrid
• Large enterprise customers: dedicated DB or hybrid

If you want, I can give you:

1. a recommended architecture diagram,
2. a stack for AWS/GCP/Azure, or
3. a decision matrix based on your exact SaaS type.