What do teams get wrong about using Postgres RLS as their primary authorization control?

Why This Matters for Security Teams

Postgres row-level security can be useful, but teams get into trouble when they treat it as the full authorization layer instead of one enforcement point. RLS only decides which rows are visible in a given query path. It does not replace identity governance, approval workflows, privilege reviews, or cross-system policy consistency. That matters because many applications now combine Postgres with services, queues, caches, ETL jobs, and API layers that may bypass the database policy entirely. NHI Management Group’s Ultimate Guide to NHIs — Standards frames this as a visibility and lifecycle problem as much as an access problem, especially where service accounts and API keys outnumber human identities. The control is also fragile when policy intent lives only in SQL, because the business meaning of access changes faster than schema and function logic do. For teams trying to reduce blast radius, that gap is where mistakes become outages or data exposure. In practice, many security teams discover RLS gaps only after a new service or migration has already bypassed the database policy, rather than through intentional governance testing.

How It Works in Practice

RLS is strongest when it is treated as a database guardrail that complements a central authorization decision, not when it is asked to carry the entire burden. In practice, the application or policy layer should first decide whether a caller may act at all, then Postgres should filter the rows that remain in scope. That separation keeps business rules in a more governable layer while still giving the database a last-mile enforcement role. For security teams, the key design questions are: who can set the session context, how tenant or principal identity gets mapped into SQL, and how policies are tested when application paths change. NIST guidance on access control in NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because it emphasizes consistent enforcement, least privilege, and auditable control operation rather than relying on a single technical mechanism. The NHIMG research page also shows why this matters operationally: the Ultimate Guide to NHIs — Standards highlights that NHI governance must include visibility, rotation, and offboarding, not just permission filtering. A practical implementation often includes:

• central policy decisions outside the database for sensitive actions
• RLS policies keyed to a trusted session identity or tenant claim
• separate controls for admin, migration, and service-to-service access
• tests that verify every data path, not only the primary application query path

These controls tend to break down when multiple services access the same tables with different connection patterns, because one overlooked path can bypass the intended authorization model.

Common Variations and Edge Cases

Tighter database enforcement often increases operational overhead, requiring organisations to balance stronger row filtering against policy sprawl and migration complexity. Some teams use RLS effectively for multi-tenant SaaS isolation, while others struggle because they expect it to solve admin access, approval logic, and auditability at the same time. Best practice is evolving on how much policy should live in SQL versus a dedicated authorization service, and there is no universal standard for this yet. The right answer depends on how many data stores exist, how often schema changes occur, and whether analytics or batch jobs need privileged access that should be separately governed. Edge cases matter: RLS can be bypassed by superuser roles, badly designed views, replication jobs, ORMs that open alternate sessions, or ETL pipelines that extract data outside the application path. It can also become brittle when business logic changes frequently, because policy edits in SQL are harder to review and reason about than centralized policy code. For teams that already have strong identity and entitlement governance, RLS is a useful compensating control. For teams without that foundation, it often becomes a false sense of security rather than a primary authorization strategy. The common failure mode is assuming the database can compensate for weak upstream identity discipline, when the real problem is that authorization was never centrally defined in the first place.

Related resources from NHI Mgmt Group

• What do teams get wrong about using session tokens for backend authorization checks?
• What do teams get wrong about role-based access control in consumer apps?
• What do teams get wrong about using NAT as a security control?
• What do security teams get wrong about using liveness detection as a standalone fraud control?