Database Multi-Tenant Architecture: Three Patterns

Multi-tenant database design is one of the most consequential early decisions. Three patterns; pick on tenant size and isolation needs.

Why pattern matters

Wrong pattern: noisy-neighbor problems; cross-tenant data leak risk; cost spirals.

Right pattern: bounded blast radius; predictable cost; easy compliance.

Three patterns

• 1. Shared schema (tenant_id column).
• 2. Schema-per-tenant (one schema per tenant).
• 3. Database-per-tenant (one DB per tenant).

Tradeoffs per pattern

Shared: cheapest; weakest isolation.

Schema-per-tenant: middle ground; harder to operate at high tenant count.

DB-per-tenant: strongest isolation; most expensive; best for enterprise tenants.

Migration cost

Shared to schema: query rewrites; backfill data.

Schema to DB: ops complexity; bulk operations harder.

Most teams stay on the pattern they started; migration is rare and painful.

Antipatterns

• Shared schema for enterprise tenants. Compliance + isolation issues.
• DB-per-tenant for thousands of small tenants. Operational nightmare.
• Mixing patterns within one app. Complexity.

What to do this week

Three moves. (1) Apply this pattern to your most-loaded table. (2) Measure query latency / write throughput before/after. (3) Document the win and the constraint so the next refactor inherits the knowledge.