Agent skill · software engineering · sickn33
saas-multi-tenant
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.
Why this skill is useful
Adds detailed implementation patterns for multi-tenant architectures in PostgreSQL and TypeScript, including RLS policies and tenant-aware middleware.
What it needs
Requires postgresql, typescript installed locally. About 7k tokens when loaded. Last updated 2026-08-07. 44,571 stars on the source repository.
What this skill does
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 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 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 tenantid 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 tenantid 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 tenantid 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 currentsetting('app.currenttenantid'). 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. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills sickn33/saas-multi-tenant--eca12c