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

Multi-tenant database design is one of the most consequential early decisions. The wrong pattern produces noisy-neighbour problems, data-leak risk, and cost spirals that compound over years.

• Wrong pattern cost. Noisy-neighbour problems, cross-tenant data leak risk, cost spirals as tenant count grows.
• Right pattern. Bounded blast radius, predictable per-tenant cost, easier compliance audit.
• Early decision. Once tenants exist, switching patterns is migration-painful; the founding choice locks in for years.
• Per-tenant economics. Pattern choice decides the marginal cost of adding a tenant; this drives the business model.

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

Each pattern occupies a point on the cost-versus-isolation curve. Pick by tenant size, isolation requirements, and operational maturity.

• Shared schema. Cheapest; weakest isolation; tenant_id column on every row; default for high-tenant-count SaaS.
• Schema-per-tenant. Middle ground; better isolation; operationally harder once tenant count exceeds a few hundred.
• DB-per-tenant. Strongest isolation; most expensive; best fit for enterprise tenants with compliance demands.
• Hybrid. Shared for free/standard tiers, DB-per-tenant for enterprise; the operational complexity is real.

Migration cost

Most teams stay on the pattern they started with. Migration is rare and painful; understand which migrations are feasible before you commit.

• Shared to schema-per-tenant. Query rewrites, data backfill, app changes; weeks to months of work.
• Schema to DB-per-tenant. Ops complexity grows linearly with tenants; bulk operations get harder.
• Migration tooling. Each cloud DB has different migration story; AWS DMS and similar help but do not eliminate the pain.
• Default behaviour. Most teams stay; migration is rare and chosen only under explicit pressure.

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.