RLS sounds great until it isn't

This post details the challenges and foot-guns of using PostgreSQL's Row Level Security (RLS). It highlights issues with policy management and syncing with application code, connection pooling complexities with PgBouncer leading to the need for session-local variables, performance degradation due to RLS acting as an extra WHERE clause on every query, and the potential for attack surface amplification. It also discusses how RLS policies can be bypassed by table owners or superuser roles. Performance implications are demonstrated with a benchmark showing significant latency increases due to non-cached function evaluations within policies, and the use of `InitPlan` to mitigate this. The post also explores the complexity of managing related data modifications (e.g., sandwich making and grocery list updates) and suggests `SECURITY DEFINER` functions as a pattern to bypass RLS for specific operations, while noting the challenges of versioning and syncing these functions with application code.