saas-multi-tenant

name	saas-multi-tenant
description	Design and implement multi-tenant SaaS architectures with row-level security, tenant-scoped queries, shared-schema isolation, and safe cross-tenant admin patterns in PostgreSQL and TypeScript.
type	skill
created	2026-02-27T00:00:00.000Z
domain	security
category	app-security
risk	safe
source	community
tags	["skill","security","app-security","saas","multi","tenant"]

SaaS Multi-Tenant Architecture

When to Use This Skill

• The user is building a SaaS application where multiple customers share the same database
• The user asks about tenant isolation, row-level security, or data leakage prevention
• The user needs to scope every database query to a specific tenant without manual WHERE clauses
• The user asks about shared-schema vs schema-per-tenant vs database-per-tenant tradeoffs
• The user is implementing admin endpoints that must access data across tenants
• The user needs to add tenant_id columns to an existing single-tenant application
• The user asks about PostgreSQL RLS policies for tenant isolation
• The user is building tenant-aware middleware in Express, Fastify, or Next.js API routes

Do NOT use this skill when:

• The user is building a single-user application with no shared infrastructure
• The user asks about authentication only without tenant scoping (use an auth skill instead)
• The user needs general database schema design without multi-tenancy requirements

Core Workflow

1. Determine the tenancy model. Ask the user about their scale expectations and isolation requirements. For most SaaS apps under 1000 tenants, shared-schema with a tenant_id column on every table is the correct default. Schema-per-tenant adds operational overhead (migrations run N times). Database-per-tenant is only justified when tenants have regulatory data residency requirements.

2. Add tenant_id to every tenant-scoped table. The column must be NOT NULL, type UUID or TEXT, and included in every composite index. Never allow a tenant-scoped table to exist without this column — a missing tenant_id is a data leak waiting to happen.

3. Set up PostgreSQL Row-Level Security (RLS). Create a policy on each tenant-scoped table that filters rows by current_setting('app.current_tenant_id'). This acts as a database-level safety net — even if application code forgets a WHERE clause, RLS blocks cross-tenant reads.

4. Build tenant-aware middleware. At the start of every request, extract the tenant_id from the authenticated session or JWT claims. Set it on the database connection using SET LOCAL app.current_tenant_id = '...' inside a transaction. Every subsequent query in that request inherits the tenant scope automatically.

5. Scope all ORM queries by tenant. If using Prisma, apply a global middleware that injects into every , , , and call. If using Drizzle, create a base query builder that includes the tenant filter. Never rely on developers remembering to add the filter manually.