When building a SaaS product, most engineers reach for the simplest database model: one table, a tenant_id column, and row-level security. It works — until it doesn’t.
The Three Models
Shared schema is the default. Every tenant’s data lives in the same tables, filtered by tenant_id. It’s cheap, fast to ship, and scales surprisingly well up to a few hundred tenants. The risk is blast radius: a bad migration or query can affect every customer at once.
Schema-per-tenant gives you database-level isolation. Each tenant gets their own Postgres schema. Migrations become harder, but you can snapshot, restore, and audit a single tenant without touching others. This is what I use for anything handling financial data.
Database-per-tenant is the gold standard for compliance-heavy products (HIPAA, SOC2). Each tenant is a separate database instance. The operational overhead is real — but if you’re selling to enterprise, it’s often a hard requirement.
Caching Strategy
I run a two-layer cache: Redis for hot data (user sessions, feature flags, frequently-queried aggregates) and in-memory LRU for per-request deduplication. The key insight is that most SaaS apps read the same 20% of data 80% of the time. Cache that 20% aggressively.
One pattern I’ve found underrated: request coalescing. If 50 concurrent requests ask for the same uncached value, only let one hit the database and fan the result out to the other 49.
The Tradeoffs Nobody Talks About
Horizontal scaling sounds great until you realize your websocket connections need sticky sessions, your cron jobs need distributed locking, and your search index needs to be tenant-aware. Plan for these before you need them.
Start with shared schema. Move to schema-per-tenant when you hit compliance requirements or when a single tenant’s write load starts affecting others. Never let perfect architecture block shipping.