Supabase's 30 October 2026 change: new tables need an explicit GRANT

Timeline

Who is affected

• Apps that use the Data API: supabase-js, REST, GraphQL, or direct HTTP calls to /rest/v1/ or /graphql/v1.
• Migrations that create tables in public without GRANT statements.
• AI builders, CLI scripts and Management API calls that expect new tables to be exposed automatically.
• Not affected: apps that connect to Postgres directly, tables that already exist, and tables in the storage, auth, realtime and custom schemas, which keep their current grants.

The error you will see

When a role has no grant on a table, PostgREST returns a clear error rather than failing silently:

{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

The fix: grant, enable RLS, add policies

This is Supabase's own three-step pattern for each new table. Replace your_table, and grant only what each role needs:

-- 1. Grant the privileges the role needs
grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- 2. Enable RLS
alter table public.your_table enable row level security;

-- 3. Add the policies you need
create policy "users can read their own rows"
  on public.your_table
  for select
  to authenticated
  using (auth.uid() = user_id);

Read the example carefully before pasting it. It gives anon select on the table, which only makes sense for data logged-out visitors should see. For a private table, leave out the anon line, or revoke it with: revoke all on table public.your_private_table from anon, authenticated, service_role; and grant back only what you need.

RLS does not change, and a GRANT is not protection

Supabase says RLS behaviour remains unchanged. Grants decide whether a role can reach a table at all; RLS decides which rows that role can see. You still need both.

The risk is the hurried fix. Supabase's RLS guide warns that a table in an exposed schema without RLS is readable and writable by any role with a grant on it. Adding grant select, insert, update, delete ... to anon on a table without RLS turns a 42501 error into an open table.

Check your project

• Table Editor shows a Data API exposure badge on each table.
• The Security Advisor flags affected tables and shows remediation SQL.
• To adopt the new behaviour early, Supabase gives alter default privileges statements that revoke default grants on future tables and sequences in public.
• For projects that opted in early, Supabase also documents rollback statements that restore the old defaults for future tables; use them only if you understand that every new table will be exposed again.

-- Supabase's opt-in for existing projects (future tables only)
alter default privileges for role postgres in schema public
  revoke select, insert, update, delete on tables from anon, authenticated, service_role;

alter default privileges for role postgres in schema public
  revoke usage, select on sequences from anon, authenticated, service_role;

Where Launch Lock helps

The change itself is safe: it makes exposure an explicit decision. What goes wrong is the fix applied under pressure, such as a builder prompt that grants everything to anon. Launch Lock tests every table of your live app from the outside with the public key and two test accounts, so you see which tables anonymous visitors and other users can read or write after your grants, with the corrected SQL for each finding.

Questions

Guides and answers

• Supabase "permission denied for table": why it happens and how to fix it
• How much does a vibe code audit cost?
• Is my Lovable app secure? What to check