row-level-security-patterns

Implement row-level security policies for multi-tenant PostgreSQL databases.

Updated Mar 29, 2026
One-click install
npx skills add https://github.com/marquesfelip/agents-and-skills --skill row-level-security-patterns
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: row-level-security-patterns
Source: https://github.com/marquesfelip/agents-and-skills/tree/main/skills/row-level-security-patterns
Command: npx skills add https://github.com/marquesfelip/agents-and-skills --skill row-level-security-patterns

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Row-level security patterns address tenant isolation at the database layer for multi-tenant apps, preventing data leakage across tenants by enforcing access policies.

Core Features & Use Cases

  • Enables ROW LEVEL SECURITY on tenant-scoped tables and forces RLS to ensure policy enforcement.
  • Defines separate READ (USING) and WRITE (WITH CHECK) policies tied to per-tenant context.
  • Sets per-transaction tenant context using SET LOCAL or set_config, avoiding leakage with connection pools.
  • Provides admin/migration bypass patterns using dedicated roles and SECURITY DEFINER functions for privileged operations.
  • Includes testing strategies to validate cross-tenant isolation and absence of data leakage.

Quick Start

Enable RLS on tenant-scoped tables, define USING and WITH CHECK policies referencing current_setting('app.tenant_id', TRUE), and enforce tenant context per transaction with set_config('app.tenant_id', 'tenant-id', TRUE) and SET LOCAL.

Frequently Asked Questions about row-level-security-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prevent cross-tenant data leakage in a shared schema PostgreSQL database?

You prevent cross-tenant data leakage by enabling row-level security on tenant-scoped tables and defining USING and WITH CHECK policies tied to per-transaction tenant context. This enforces strict tenant isolation during read and write operations.

How does PostgreSQL row-level security handle tenant isolation with connection pools?

PostgreSQL row-level security handles connection pools by setting per-transaction tenant context using SET LOCAL or set_config. This ensures the tenant identifier does not leak across pooled connections between distinct transactions.

How do I run database migrations without row-level security policies blocking admin access?

You run migrations by implementing admin bypass patterns using dedicated roles and SECURITY DEFINER functions. This grants privileged operations access to tenant-scoped tables without being restricted by enforced row-level security policies.

What is the difference between USING and WITH CHECK policies in PostgreSQL row-level security?

In PostgreSQL row-level security, USING policies enforce tenant isolation during read operations by filtering visible rows, while WITH CHECK policies validate write operations to ensure inserted or updated rows conform to the current tenant context.

How do I test row-level security policies to ensure no cross-tenant data leakage occurs?

You test row-level security by implementing comprehensive testing strategies that validate cross-tenant isolation. This verifies that policies correctly enforce tenant boundaries and confirm the absence of data leakage across tenants.