Choosing a Multi-Tenancy Isolation Strategy

Multi-tenancy is one of the first architecture forks in any SaaS. The decision isn't ideological — it's about blast radius, cost and operational complexity.

The two ends of the spectrum

• Database-per-tenant — strong isolation, per-tenant backup/restore and noisy-neighbour immunity, at the cost of migration fan-out and connection overhead. On a multi-venue booking platform, each venue got its own database selected by API-key middleware. That made per-venue data guarantees trivial, but every schema change had to run across N databases.
• Shared schema with a tenant_id column — cheap, one migration, one connection pool, but every query must be scoped and a single bad query can leak across tenants. A multi-vendor marketplace I architected scoped everything by company_id and pushed isolation into the application layer.

How I decide

Isolation strength should match the cost of a cross-tenant leak, not the size of the tenant.

1. Regulated or high-value data → lean toward physical isolation.
2. Thousands of small tenants → shared schema, invest in query guards and tests.
3. A middle path: shared schema now, with a tenant_id that maps cleanly onto a future shard key, so you can migrate hot tenants out later without a rewrite.

The mistake I see most often is choosing per-tenant databases for thousands of tiny tenants — you inherit all the migration pain and none of the scale benefit.