Multi-Tenant Databases

Schema per tenant; row-level.

Overview

Multi-tenant database design chooses how to isolate tenant data: row-level (tenant_id on every table), schema-per-tenant (Postgres schemas as the boundary), or per-tenant database (the strongest isolation, the highest cost). Each model trades scale against isolation differently. Most SaaS architectures land on hybrid: row-level for the main fleet, schema-per-tenant for select customers, per-tenant database for enterprise tier where the contract demands it.

• Schema per tenant or row-level. Two main isolation models with very different scale and isolation profiles.
• Row-level isolation. tenant_id column on every table; scales to large tenant counts; needs disciplined enforcement to avoid data leaks.
• Schema per tenant. Per-tenant Postgres schema; stronger isolation than row-level; harder to scale beyond a few hundred tenants.
• Per-tenant database plus hybrid. Strongest isolation, highest cost; matches enterprise; hybrid (row-level default plus dedicated for enterprise) is the common steady state.

The approach

The practical approach is row-level by default for the main fleet (with Postgres RLS or strict application-layer scoping), dedicated database for enterprise customers whose contracts demand it, schema-per-tenant only when the tenant count fits the operational complexity, and documented per-table isolation pattern committed to the schema documentation so the model is reviewable. The choice locks in the architecture for years; getting it right at design time matters more than for almost any other database decision.

• Row-level default. tenant_id on every table; supports the main fleet at scale; the cheapest isolation model.
• Dedicated for enterprise. Per-tenant database for top-tier customers; the contract often demands it.
• Postgres RLS. Database-enforced row isolation; catches application bugs that bypass the ORM’s tenant scoping.
• Application enforcement plus documented model. ORM scoping by tenant_id at the application layer; per-table isolation pattern committed to the schema documentation.

Why this compounds

Multi-tenant database discipline compounds across the SaaS lifetime. Each correct isolation choice avoids the painful migration when an enterprise customer demands isolation that the row-level model cannot provide; each documented model survives team turnover; the team builds intuition for tenant-isolation tradeoffs that pays off on every new feature.

• Cost efficiency. Row-level scales without exponential cost; per-tenant database is reserved for tiers that pay for it.
• Isolation. Dedicated database for enterprise produces real protection; the contract is satisfied at the data layer.
• Operational fit. Right model for the workload; the team operates at the complexity the workload actually requires.
• Institutional knowledge. Each tenant decision teaches isolation patterns; the team learns where to draw the boundary.

Multi-tenant database discipline is an architectural discipline that pays off across years. Nova AI Ops integrates with database telemetry, surfaces tenant patterns, and supports the team’s SaaS architecture discipline.