Industry
Multi-Tenant SaaS Architecture: Why Database-Per-Tenant Wins
Shared schema with tenant_id is cheap to build and expensive to operate. Here is when database-per-tenant pays off — and when it doesn't.
AAmy Chen··8 min read
Every B2B SaaS hits this fork in the road on day one: shared schema with a tenant_id column, or one database per customer. AssetMon picked the second. Here is why — and the trade-offs.
Shared schema (row-level)
- ✓ Cheap to host; one Postgres for thousands of tenants.
- ✓ Schema migrations run once.
- ✗ One missed WHERE clause is a data breach.
- ✗ Noisy-neighbour queries hurt everyone.
- ✗ Per-tenant backup/restore is awkward.
Database-per-tenant
- ✓ True isolation — accidental cross-tenant reads are physically impossible.
- ✓ Per-tenant backup, restore, encryption, and even region pinning.
- ✓ Performance issues are localised.
- ✗ Migration tooling has to fan out across every DB.
- ✗ Connection-pool engineering is non-trivial.
The cost is exaggerated
Modern Postgres handles thousands of databases per instance. Connection pooling (PgBouncer, RDS Proxy) makes the connection cost manageable. The operational complexity is solvable with one engineer and good migrations tooling.
Our take
For B2B apps where data sensitivity is high, the auditor will sleep better with database-per-tenant. We built it into AssetMon from day one for exactly this reason.
#multi-tenant architecture#SaaS#database per tenant#data isolation