What is RLS (Row Level Security)? The setting that keeps your Supabase data private

What it actually is

Row Level Security (RLS) is a Postgres feature (every Supabase project is a Postgres database underneath) that decides which individual rows of a table a request can see or touch, not just whether it can reach the table at all. Think of your API key as the key card that gets someone into the building lobby; RLS is the lock on each apartment door. Being in the building doesn’t mean every door opens for you. Once RLS is on for a table, every query (from your app, the auto-generated REST API, even the SQL Editor) gets an invisible WHERE clause tacked on, built from policies you write, like “only rows where user_id matches whoever is logged in.”

Why your AI just did this

Supabase turns tables in your public schema into a REST endpoint via PostgREST. That part hasn’t changed. What changed: since May 30, 2026, new projects stop granting anon and authenticated access to a table the moment it’s created, so a fresh table now returns a permission-denied error until someone runs grant select on public.<table> to anon;. Projects started earlier still auto-expose new tables the old way. Either way, once a table is reachable, RLS decides which rows come back. That’s why your AI enables it and writes policies. Without them, a reachable table answers to anyone holding your anon key, which sits inside your frontend bundle, visible in dev tools. So when your AI runs alter table profiles enable row level security; and create policy "select own profile" on profiles for select using ((select auth.uid()) = user_id);, it makes sure select * from profiles from a logged-in user only returns that user’s own row.

When you’ll run into it

• You ask your AI “why is my query returning nothing?” after adding a new table. The answer is often RLS on with zero policies attached, and the default with no policies is deny-everything, not allow-everything.
• On a project started after May 30, 2026, a fresh table returns a permission-denied error on first query. A missing grant, separate from RLS.
• Someone flags “your Supabase is public?” after opening your site’s network tab, grabbing the visible anon key, and testing whether your tables respond without logging in.
• You create a table through the Table Editor (RLS turns on automatically) versus the SQL Editor, a migration, or an ORM like Prisma (RLS stays off until you run enable row level security yourself). Same project, two different defaults.

What to check

• Run select tablename, rowsecurity from pg_tables where schemaname = 'public'; (or Database → Policies in the dashboard) to see which tables have RLS on
• For tables with RLS on, confirm at least one policy exists. RLS with no policies blocks all access, which looks like a bug but is the safe default
• For tables with RLS off, confirm nothing sensitive is in them and that anon/authenticated aren’t granted on them. Pre-May 2026 projects grant new tables automatically, so “RLS off” can still mean wide open
• Check policies use (select auth.uid()), not a bare using (true). That phrase means everyone, no restriction, and the select wrapper is Supabase’s current recommended form
• If you added an event trigger to auto-enable RLS on new tables, it only covers tables created afterward. Existing ones still need RLS by hand

Say it like a dev

Instead of: “Make sure random people can’t read other users’ data.” Say: “Enable RLS on the orders table and add a policy so a user can only select and update rows where user_id matches (select auth.uid()).”

Instead of: “Why is my table empty when I query it from the app?” Say: “Check whether RLS is enabled on this table with no matching policy for the current role. That would explain the empty result instead of an error.”

Instead of: “Lock down the database.” Say: “Audit every table in the public schema for RLS status and grants, and list any policy that uses using (true).”