Building Multi-Tenant Row-Level Security in PostgreSQL: A Production Pattern
Most multi-tenant SaaS applications implement tenant isolation in the application layer. You check request.tenant_id before querying, validate ownership in your service layer, maybe add a middleware that throws if the IDs don't match. It works—until it doesn't.
I've watched this pattern burn production systems. A junior developer forgets one authorization check. A refactor moves logic around and the guard rails disappear. A cron job runs with elevated privileges and suddenly exports competitor data. These aren't hypotheticals—I've debugged all three in CitizenApp.
Database-enforced Row-Level Security (RLS) flips the model: the database itself refuses to return rows that don't belong to your tenant, regardless of what code tries to access them. This is belt and suspenders, but the belt actually works.
Why Application-Layer Isolation Fails
