Fix Supabase Auth, Row Level Security & Database Performance

Row-level security is the whole security model

In a Supabase application the browser talks to the database directly, so the policies are not one layer of protection among several — they are the only one. A permissive policy is equivalent to publishing the table.

The test is straightforward and worth doing today if nobody has: log in as one ordinary user and attempt to read another user's rows. If anything comes back, the rest of the work waits.

Common policy failures

The same handful of mistakes account for most real-world leaks.

• Policies written for reading but not for writing, so anyone can modify what they cannot see.
• A policy that queries a table which itself has a policy referring back, producing infinite recursion.
• Role checks based on data the client supplies rather than on the authenticated session.
• Service-role keys used in browser code, which bypasses every policy in the database.
• Tables added later that nobody enabled policies on at all.

Policies are queries, so they need indexes

Every policy runs on every row touched by every request. A policy that performs a lookup against an unindexed column turns a fast query into a slow one across the entire application, and the symptom is general sluggishness rather than one obviously slow page.

The columns policies filter on need indexes as much as the ones your application filters on — more, because they run more often.

Connections and pooling

PostgreSQL has a hard limit on simultaneous connections, and serverless applications open them enthusiastically. This produces an error under load that looks like the database being down when it is merely full.

The fix is using the pooled connection endpoint for application traffic and keeping the direct connection for migrations. It is a configuration change, and it is one of the most common causes of a Supabase app failing exactly when it starts succeeding.