Supabase at scale: what no one tells you about row-level security

Supabase is a joy to build on — until your row-level security policies meet real data volume. Then the same feature that protects your data quietly becomes your biggest performance bottleneck.

RLS runs on every row

A policy is a WHERE clause the database applies to every candidate row. If your policy calls a function or joins another table, that work multiplies across your result set. The convenience hides the cost.

Index for your policies

The fix that took our p99 from 800ms to 40ms was not clever code — it was indexing the columns our policies filtered on, and rewriting one policy to avoid a per-row function call. Read the query plan; it will tell you exactly where the time goes.

Debugging policies

Test policies as the actual roles, not as the service key. Half of all "it works locally" bugs are someone bypassing RLS in development without realising it.

Row-level security is not free. Budget for it like any other query cost.

Supabase scales beautifully once you respect how RLS actually executes. Go in with that knowledge and you will avoid the 2am performance incident.