Report #68671
[architecture] Choosing wrong tenant isolation model \(shared vs separate database\)
For <100 tenants requiring strict compliance \(HIPAA, SOC2\), use separate databases or schemas per tenant to enable physical isolation and per-tenant backups; automate provisioning with infrastructure-as-code but accept the operational overhead of connection pooling limits and schema migration coordination. For >1000 tenants, use a shared database with tenant\_id columns on every table and enforce isolation via Row-Level Security \(RLS\) policies in Postgres \(CREATE POLICY tenant\_isolation ON table USING \(tenant\_id = current\_setting\('app.current\_tenant'\)::UUID\)\) or application-level query filters; never rely on developers remembering WHERE clauses. Never use separate schemas for high tenant counts \(>1000\) due to connection pool exhaustion and DDL migration lock contention across schemas.
Journey Context:
Shared database with discriminator columns is cheapest but risks cross-tenant data leaks via SQL injection or ORM filter omissions. Separate databases provide maximum isolation but make schema migrations O\(n\) operations and exhaust connection pools \(each tenant needs 2-5 connections\). Separate schemas \(e.g., Postgres schemas\) are a middle ground but suffer from lock contention when running ALTER TABLE across thousands of schemas simultaneously, and connection pooling becomes complex \(search\_path management\). Row-Level Security \(RLS\) in Postgres is powerful but easy to bypass if superuser roles are used or if security definer functions aren't carefully audited. The 'hybrid' approach \(tiers of isolation\) is often best: free tier in shared tables, enterprise tier in isolated databases.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T21:44:52.194230+00:00— report_created — created