Supabase Row Level Security: Five Policy Examples

RLS is off until you enable it on each table. Tables created from SQL don't turn it on for you, so check every table in the exposed schema. Once it's enabled with no policies, nobody except the service role can read or write rows, which is the safe default.

1. Enable it: alter table notes enable row level security.
2. Add a select policy for the authenticated role: using (user_id = (select auth.uid())).
3. Add an insert policy with a check clause: with check (user_id = (select auth.uid())).
4. Add update and delete policies with the same ownership condition.
5. Test as an anonymous user and as two different signed-in users.

Two clause types matter. USING filters which existing rows a request can see or modify. WITH CHECK validates the new values being written. An update policy usually needs both, or a user could change a row's owner to someone else. Wrapping auth.uid() in a select is a commonly recommended way to let Postgres evaluate it once per statement rather than per row.

These five cover most products:

• Owner-only rows. Each row has a user_id; policies compare it to the current user. Fits notes, drafts, personal settings.
• Team or organization membership. A memberships table links users to organizations. A row policy checks whether the current user has a membership in the row's org_id, using an exists subquery. Fits multi-tenant SaaS.
• Public read, owner write. A select policy for everyone (or anon and authenticated) with insert, update and delete restricted to the owner. Fits published profiles or posts.
• Role-based access. Read the role from a claim you control, such as app_metadata in the JWT, and allow admins broader access. Never base a policy on user_metadata, which users can edit themselves.
• Shared records with a join table. A document is visible if the user appears in a document_shares table for it. Fits collaborative documents.

For the membership pattern, put an index on the columns the policy filters, such as memberships.user_id and org_id, because the subquery runs for many rows.

Policies fail silently: a wrong policy usually returns zero rows, not an error, and a too-open policy returns everything. Test both directions.

• In the SQL editor, set the role to authenticated and set the JWT claims to a test user's ID, then run selects and writes and confirm only expected rows come back.
• Repeat with a second user and with the anon role.
• From your app's client library, try to read and update another user's record by ID. The result should be empty or rejected.
• Check writes as well as reads: try inserting a row with someone else's user_id.
• Add these checks to your test suite so a later migration can't loosen a policy unnoticed.

Remember the service role key bypasses RLS entirely. It belongs only in trusted server code, never in a browser or mobile app.

The usual causes of RLS incidents:

• Forgetting to enable RLS on a new table, especially helper and join tables.
• Views. A view can run with its owner's rights and skip the underlying table's policies unless you configure it to run as the invoking user (available in newer Postgres versions). Check how each view is defined.
• Functions marked security definer that read tables without checking who's calling.
• Policies that use user-editable metadata for authorization.
• Storage buckets and realtime channels, which have their own access rules and aren't covered by table policies.

Treat a cross-tenant read as a top-severity event in your incident severity levels.

RLS is a strong last line of defense, but it doesn't replace application checks, rate limits or input validation. It can also become hard to reason about when many policies stack up. Keep policies short, name them clearly, and store them in migration files so changes go through review. If you're outgrowing the hosted platform, consider the tradeoffs in MongoDB Atlas vs AWS RDS vs Supabase and, for planning a move, the Supabase to RDS migration guide. Backups matter too: see the Postgres backup checklist.