PostgreSQL RLS Is Fail-Closed, But Is It Fast? Making django-rls-tenants Index-Friendly

A couple of days ago I published a post about why PostgreSQL Row-Level Security is the right approach to Django multitenancy . The short version: application-level filtering is opt-in, RLS is opt-out. One fails by leaking data, the other fails by returning nothing. I still stand by all of that. But after spending more time with RLS on actual data -- not the neat 50-row test tables I started with -- I ran into something the PostgreSQL documentation doesn't make obvious. RLS policies have a performance cost, and it's not where you'd expect it. The isolation itself is rock solid. The problem is the query planner. PostgreSQL has opinions about how RLS policy expressions get evaluated, and those opinions can prevent your indexes from doing their job. I only noticed because a query that should have been fast wasn't, and EXPLAIN told me a story I didn't expect. This post is about what I found, why it happens, and what changed in django-rls-tenants 1.1.0 to fix it. The Problem: RLS Policies Ca