SaaS Multi-Tenant Database

Introduction

SaaS apps store many tenants' data in one DB. Strategies: shared schema + tenant_id, schema per tenant, DB per tenant. Each has trade-offs.

Understanding the topic

Core concepts to understand:

• Shared: tenant_id column + RLS.
• Schema-per-tenant: medium isolation.
• DB-per-tenant: max isolation, max ops cost.
• Index every tenant_id — lookups always filter on it.
• Backups, migrations and noisy neighbors must be considered.

Syntax reference

Visual workflow / architecture:

Shared schema (most common):
  every table has tenant_id; RLS filters; tenant_id leftmost in indexes.
Schema-per-tenant:
  one CREATE SCHEMA per tenant; queries set search_path.
DB-per-tenant:
  enterprise customers; biggest isolation.

Real-world use

Notion, Slack and Linear use shared schema with strong RLS. Some enterprise vendors offer DB-per-tenant for big customers.

Best practices

• tenant_id leftmost in every index.
• RLS for defense in depth.
• Test noisy-neighbor scenarios.

Hands-on exercise

Interview preparation — practice these questions:

• Q1. Three multi-tenant strategies and trade-offs.
• Q2. Why tenant_id leftmost in indexes?
• Q3. RLS in multi-tenant.
• Q4. Migrations across tenants.
• Q5. Noisy-neighbor handling.