Running a SaaS is different from running a side project. You need reliability, isolation, and a path to scale. Here's how to architect it right from day one.

The Core Challenge

Multi-tenant SaaS has conflicting requirements:

Shared resources for cost efficiency
Tenant isolation for security and reliability
Per-tenant customization for flexibility
Scaling as you grow

Getting this balance right from the start saves expensive rewrites later.

Architecture Options

Option 1: Shared Database (Simplest)

All tenants share one Postgres database with a tenant_id column.

Pros: Cheapest, simplest Cons: Data isolation risk, harder to scale per-tenant

-- Every table has tenant_id
SELECT * FROM tasks WHERE tenant_id = :tenant_id

Option 2: Schema per Tenant

Each tenant gets their own Postgres schema.

Pros: Better isolation, easier per-tenant queries Cons: Schema migrations multiply, more complex

SET search_path TO tenant_123;
SELECT * FROM tasks;

Option 3: Database per Tenant

Separate Postgres databases per tenant.

Pros: Complete isolation, independent scaling Cons: Expensive at scale (100+ tenants), complex ops

Recommended Stack for SaaS

Starting Out (< 500 tenants)

1x Hetzner CX31 (4 vCPU, 8GB RAM) — $12/mo
Self-hosted Postgres with schema-per-tenant
Redis for sessions and caching
Cloudflare for CDN and DDoS

Growing (500-5000 tenants)

2x Hetzner CX41 (4 vCPU, 16GB RAM) — $24/mo
Self-hosted Postgres (upgrade to larger instance)
Managed Redis (Upstash) — $10/mo
Read replicas for read-heavy workloads

Scaling (5000+ tenants)

Managed Postgres (Neon or Supabase) — $25-100/mo
Multiple app servers behind load balancer
CDN for static assets
Object storage for files (S3 or R2)

Database per Tenant: When to Use It

If your SaaS has:

Strict data isolation requirements (enterprise customers)
Very different per-tenant schemas
Tenants with huge data (100GB+)
Compliance requirements (SOC2, HIPAA)

Then database-per-tenant makes sense. Otherwise, schema-per-tenant is the sweet spot.

Scaling Strategies

Vertical Scaling First

Start with bigger VPS before adding complexity:

CX21 → CX31 → CX41 → CX51

Horizontal Scaling When Needed

Add more app servers:

openclaw scale --replicas 2

Read Replicas for Reports

Heavy analytics queries? Add a read replica:

openclaw db replica add mydb --read-only

Reliability Best Practices

Health Checks

OpenClaw auto-restarts on failed health checks:

{
  "healthCheck": "/health",
  "healthCheckInterval": 30
}

Database Backups

# Daily automated backups, 7-day retention
openclaw db backup mydb --schedule "0 2 * * *" --retention 7

Uptime Monitoring

openclaw alerts set --type health --telegram --threshold 3

Cost at Scale

| MRR | Recommended Stack | Monthly Cost | |-----|-------------------|--------------| | $0-1K | Hetzner CX21 + self-hosted DB | $6-12 | | $1K-5K | Hetzner CX31 + managed DB | $25-40 | | $5K-20K | Hetzner CX41 + managed services | $50-100 | | $20K+ | Multi-region + dedicated resources | $200-500 |

The goal: hosting should be < 5% of MRR until you're at real scale.

SaaS Hosting: Architecture for Production Multi-Tenant Applications