There's a particular kind of conundrum that has derailed more architectural decisions than I care to count. You know the one - performance optimization. What do you trade off for what and in what scenario and what might it achieve. I had to sit with one of those conundrums recently.
For a multi-tenant platform, I'd chosen Postgres Row-Level Security for tenant isolation — each tenant's rows locked behind a policy, enforced at the database level, no application code involved. Clean, elegant, one less thing to accidentally screw up in your ORM layer. Then I spent a weekend second-guessing myself.
So I did what you should always do before making an architectural decision: I measured it.
What RLS actually does (the one-sentence version)
You attach a policy to a table. Every query against that table gets an invisible WHERE clause appended by Postgres, based on who's asking. A regular app user asking for rows gets only their rows. A superuser bypasses it entirely. That's it. The question is whether that invisible WHERE clause costs you anything meaningful at scale.
The setup
1 million rows in a single table. One tenant owns roughly 10% of them (~100k rows). I ran 50 timed executions per condition, threw away the first 3 as warmup, and measured p50, p95, and p99 latency. (p95 means 95% of your queries finished faster than this number — it's your realistic bad day, not your theoretical worst case.)
Four conditions:
A — superuser, no index → RLS completely bypassed
B — app_role, no index → RLS active, planner on its own
C — superuser, with index → RLS bypassed, index benefit only
D — app_role, with index → RLS active + index (this is production)
Three query types: a simple LIMIT 100 fetch, a filtered scan with a second condition, and a full COUNT(*). The idea was to cover the range from "barely touches the table" to "has to read everything."
Finding 1: RLS overhead is basically noise
Compare A and B. Same hardware, same data, same queries — the only difference is whether RLS policies are being evaluated.
At p95, A vs B differs by less than 2% across every query type. On the count query — the heaviest one, which scans the entire table — A clocks in at 73.3ms and B at 74.9ms. That 1.6ms is Postgres evaluating your RLS policy. It is, to use a technical term, nothing.
The performance concern, as it turns out is focussed on the wrong thing. Policy evaluation is not your bottleneck.
Finding 2: The index is doing all the work
Now look at C and D. Same queries, but I've added an index on tenant_id.
The count query drops from ~73ms (A and B, no index) to 2.2ms (C) and 2.7ms (D). That's a 26× speedup. RLS overhead within the indexed conditions? Still less than 25%.
Here's what's happening under the hood. Without the index, Postgres launches a parallel sequential scan — it reads every single row in the table and throws away the ones that don't belong to your tenant. With the index, it goes straight to your tenant's rows and in the COUNT case, never even visits the heap at all.
The EXPLAIN plans make this embarrassingly obvious:
Without index (condition A):
Parallel Seq Scan on jobs
Filter: (tenant_id = ...)
Rows Removed by Filter: 299,876
With index (condition D):
Index Only Scan using idx_jobs_tenant_id
Index Cond: (tenant_id = ...)
Heap Fetches: 0
299,876 rows examined vs 0 heap fetches. The index doesn't just help — it changes the shape of the query entirely.
The nuance nobody talks about: secondary predicates
Here's where it gets interesting. The filtered query — which adds a second condition on top of the tenant filter — barely improves with the index. About 42ms without, about 40ms with. A 5% improvement where the count query got 26×.
Why? Because the second predicate forces Postgres to visit the actual heap rows to check the condition. The bitmap index scan narrows the candidate set using the tenant index, but it still has to physically read all ~11,000 heap blocks to evaluate the second filter. You can't index-only scan your way out of a heap fetch.
The fix, if this matters for you, is a composite index: (tenant_id, your_second_column). That lets the planner push both conditions into the index scan and skip the heap entirely. I didn't test that here — that's a follow-up post — but the query plans point directly at it.
What this actually means for you
Three things you can take away from this:
1. Index your tenant_id column. Not optional. Without it, every aggregation query scans your entire table regardless of how tight your RLS policy is. With it, your database goes from doing 300k wasted row evaluations to zero.
2. Stop worrying about RLS overhead. The policy evaluation cost is real but it's measured in microseconds. The architectural benefits — tenant isolation enforced at the database level, impossible to accidentally leak rows from a missing WHERE clause in your application code — are worth far more than 1.5ms.
3. Watch your secondary predicates. If your common queries filter on more than just tenant_id, think about whether a composite index makes sense. The planner is smart but it can only use what you give it.
The part where I admit something
I'll be honest — I already knew the likely outcome before running this. The Postgres community broadly understands that RLS overhead is index-shaped, not policy-shaped. But "broadly understood" and "here are actual numbers from a real table at 1M rows" are different things.
One caveat worth naming: this benchmark tests a simple single-condition policy — the kind that covers most multi-tenant SaaS use cases. Complex policies with subqueries or permission table joins are a different story, and not one this experiment speaks to. That's a follow-up for another day.
Measure things. Then decide.
