Choose the isolation model before the first customer

How to do it

Shared tables with a tenant column and row-level security, as Keep each customer's data apart shows, suit most apps. They need one migration, one connection pool and one backup. A schema per tenant gives cleaner restores and exports, but every migration runs once per schema. Past a few thousand schemas, catalog size slows tools and backups. A database per tenant gives the strongest separation, its own keys, region and restore. It also costs one connection pool, one backup and one upgrade per customer, so automate all three first. Many apps mix models, keeping small tenants in shared tables and moving a large or regulated customer to its own database. Store the model per tenant in a tenants table, so code reads where a tenant lives instead of assuming it. Keep the organisation as the owner of the data, as Let organisations own the shared data says.

Examples

SQL example

CREATE TABLE tenants (
  id            bigint PRIMARY KEY,
  slug          text NOT NULL UNIQUE,
  isolation     text NOT NULL CHECK (isolation IN ('shared', 'schema', 'database')),
  location      text NOT NULL,          -- schema name or connection name
  region        text NOT NULL,
  created_at    timestamptz NOT NULL DEFAULT now()
);

How to check

The repository holds a decision record that names the model, the reason and the target tenant count. The tenants table has a non-null column for the model and the database or schema of each tenant. A test creates a tenant in each model the code supports and reads a row back through the normal app code.

Sources

• AWS SaaS Tenant Isolation Strategies
• OWASP Multi-Tenant Security Cheat Sheet

Related rules

• DAT-7 Keep each customer's data apart in Data and databases
• ACC-41 Let organisations own the shared data in Accounts and identity
• DAT-73 Find and contain noisy neighbours in Data and databases