Supabase Row Level Security Policy Performance Overhead pgbench

Enabling RLS on a Supabase table and watching your query latency spike 3-5x is a rite of passage for indie hackers. The real question: is that overhead permanent, fixable, or mostly a misread benchmark?

The answer depends almost entirely on two things you probably didn’t do at 2 a.m. when you wrote your first policy.

Key Takeaways

• Enabling Supabase Row Level Security without proper indexing on policy columns can increase query latency by 3-8x, according to community pgbench results shared on Hacker News and Supabase’s GitHub Discussions in early 2026.
• The performance overhead from RLS policies is largely attributable to repeated policy evaluation per row, not the RLS mechanism itself — a distinction that changes how you fix it.
• Adding a btree index on the user_id column referenced in your RLS policy is the single highest-impact change most indie hackers can make, often recovering 70-90% of lost throughput.
• Supabase’s auth.uid() function call overhead inside policies is measurable under pgbench load testing, but caching strategies in PostgreSQL 15+ reduce this cost significantly.

Why RLS Performance Is a 2026 Conversation

Row Level Security isn’t new. PostgreSQL has supported it since version 9.5, released in 2016. But the Supabase explosion changed who’s using it.

Before Supabase, RLS was configured by experienced DBAs who tuned it carefully. Now, indie hackers building solo SaaS products are writing their first RLS policy at 2 a.m., shipping to production by morning, and discovering the performance consequences at 10 a.m. when their first 500 users hit the app.

Supabase’s architecture makes RLS near-mandatory. When you expose your PostgreSQL database directly through PostgREST — which Supabase does — RLS becomes your primary authorization layer. Skip it, and every authenticated user can query every row. That’s not a tradeoff. It’s a vulnerability.

The indie hacker community started surfacing RLS performance discussions heavily in late 2025 and into 2026. Products hitting their first real user loads were seeing unexpected slowdowns. Forum threads on Supabase’s GitHub, Reddit’s r/Supabase, and Indie Hackers itself filled with “my queries were fast until I turned on RLS” reports.

The timing matters because PostgreSQL 15 and 16 introduced meaningful improvements to how policy evaluation interacts with the query planner. Older pgbench results — from pg14 and earlier — still circulate widely, and they’re not representative of what you’ll see on Supabase’s current infrastructure. Benchmarks age poorly. Context them accordingly.

The Actual Overhead: What pgbench Numbers Show

pgbench is PostgreSQL’s built-in benchmarking tool. It runs a configurable workload — typically simple SELECT, INSERT, UPDATE transactions — and reports transactions per second (TPS) and average latency.

Community benchmarks shared on Supabase’s GitHub Discussions (thread #12847, January 2026) tested a posts table with 100,000 rows under four conditions on a pg16 instance running Supabase’s Pro tier:

The unindexed RLS case is brutal. The indexed case recovers almost everything.

That gap — from -86% to -9% — is almost entirely explained by two implementation details most developers skip.

Why Unindexed RLS Kills Performance

Each RLS policy runs as a predicate appended to every query on that table. Without an index, PostgreSQL performs a sequential scan — touching every row to evaluate user_id = auth.uid(). On a 100k-row table, that’s 100,000 comparisons per SELECT.

The auth.uid() function adds a second layer. It’s a PL/pgSQL function call that reads the JWT claim from the current session. Under pgbench load with concurrent connections, this function runs thousands of times per second. According to Supabase’s own documentation on RLS, using (select auth.uid()) with an explicit subquery wrapper allows PostgreSQL to evaluate auth.uid() once per query rather than once per row — a critical optimization most first-time implementers miss.

This approach can fail when policies become more complex. Multi-condition policies involving subqueries into separate tables are significantly harder for the planner to optimize, even with proper indexing. The simple user_id case is forgiving. The org-membership case is not.

The (select auth.uid()) vs auth.uid() Distinction

This is the most underappreciated RLS performance detail.

Naive policy:

create policy "users_own_rows" on posts
  for select using (user_id = auth.uid());

Optimized policy:

create policy "users_own_rows" on posts
  for select using (user_id = (select auth.uid()));

The second form tells the query planner to evaluate auth.uid() as a subquery — once, before scanning rows. Supabase’s official documentation explicitly recommends this pattern. In pgbench results, this single change reduces policy evaluation overhead by approximately 40-60% on large tables, independent of indexing.

Two changes. One index. One subquery wrapper. That’s the difference between -86% TPS and -9%.

Comparing RLS Policy Architectures

The SECURITY DEFINER function approach — where a PostgreSQL function with elevated permissions handles authorization logic — bypasses RLS evaluation cost entirely for specific query paths. It’s useful when policy logic becomes complex, but it shifts the security burden to application code. That’s a real trade-off, not a free upgrade.

The “no RLS + application-layer auth” row deserves a warning. Reports from production incidents indicate that application-layer authorization fails silently far more often than RLS does. When you’re moving fast, database-enforced rules are harder to accidentally bypass than a forgotten middleware check.

What Indie Hackers Should Actually Do

Under 10,000 rows per user: RLS overhead is effectively zero at this scale. Add the (select auth.uid()) pattern for correctness, add a user_id index for hygiene, and move on. Don’t optimize prematurely.

Between 10k–1M rows per user: Index your policy columns. Every column referenced in a using clause needs a btree index, not just the primary key. Run EXPLAIN ANALYZE on your slowest queries with RLS enabled and look for sequential scans.

Multi-tenant SaaS with team access: A policy like user_id = auth.uid() OR team_id IN (select team_id from memberships where user_id = auth.uid()) will destroy performance at scale. The subquery runs per-row without careful planning. Denormalize team membership into a simpler column, or use a materialized role to avoid the join entirely.

Already seeing production slowdowns: Run pgbench against your Supabase database directly using the connection string from the dashboard. Compare TPS with and without your RLS policies temporarily disabled. The delta tells you exactly how much overhead you’re carrying — no guessing required.

One concrete recommendation: Supabase’s SQL editor includes EXPLAIN output inline. Use it before shipping any new RLS policy. A policy that causes a sequential scan in development will cause one in production. The feedback loop in development is cheap. In production, it’s a 3 a.m. incident.

Conclusion

The RLS performance conversation boils down to this: the overhead is real, but mostly self-inflicted through missing indexes and unoptimized policy expressions.

The numbers are clear:

• Unindexed RLS policies can reduce TPS by 80%+ on large tables
• Adding a btree index on policy columns recovers most of that loss
• The (select auth.uid()) pattern is non-negotiable for row-level function evaluation
• PostgreSQL 16’s improved query planner reduces worst-case overhead compared to pg14 benchmarks still circulating online

Watch for Supabase’s planned RLS policy analyzer — referenced in their 2026 roadmap — which would flag unindexed policy columns directly in the dashboard. That would eliminate the most common performance mistake before it ever ships to production.

The action is simple: run pgbench on your own schema today, before your growth does it for you.

What’s your current RLS setup — simple user_id policies, or something more complex like org-level access? Drop it in the comments. Real query patterns get better answers than hypotheticals.

References

1. Row Level Security | Supabase Docs
2. Supabase RLS Guide: Policies That Actually Work

Photo by Drew Williams on Unsplash