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 ...