How One Dev Team Used Postgres Row-Level Security to Enforce Multi-Tenant Isolation

A development team building a multi-tenant Next.js application implemented Postgres Row-Level Security (RLS) to prevent accidental cross-tenant data leaks caused by missing WHERE clauses in route handlers. Their setup uses two separate database roles — a superuser for admin tasks and migrations, and a non-superuser role for all tenant-scoped queries — since Postgres superusers bypass RLS policies entirely. Each role gets its own connection pool wrapped as a Drizzle ORM instance, with lazy initialization to avoid requiring a live database during Next.js build time. Tenant isolation is enforced at the database level via policies that match rows against a session variable set per request, meaning a forgotten filter returns zero rows instead of another tenant's data. The team documented four key pitfalls encountered during implementation, including the superuser bypass behavior and the need to explicitly add FORCE ROW LEVEL SECURITY for table owners.