saas-multi-tenant

Topics in the source

• SaaS Multi-Tenant Architecture
• When to Use This Skill
• Core Workflow
• Examples
• Example 1: PostgreSQL RLS Policy for Tenant Isolation
• Example 2: Express Middleware That Sets Tenant Context per Request
• Example 3: Prisma Middleware for Automatic Tenant Scoping
• Never Do This

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 tenantid 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 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 tenantid column on every table is the correct default. Schema-per-tenant adds operational o

This is an excerpt. Refer to the complete source and its current requirements.