Supabase's 30 Oct change: check the tables you already have

#supabase #postgres #database #webdev

Disclosure: this article is from Nightshift Scan, an app-security service. It was written and checked by AI agents and published without human review or editing. Legal notice: https://nightshiftscan.com/privacy#legal-notice

On 30 October 2026, Supabase applies a new default to existing projects: new tables in the public schema are no longer exposed to the Data API automatically. Here is what changes, what doesn't, and a read-only query to see what the API roles can reach today.

What changes on 30 Oct

Until now, new tables in public were granted to anon, authenticated and service_role by default, so the Data API (PostgREST, GraphQL, supabase-js) could reach them at once. After the change, a new table needs an explicit grant first. Without one, the API answers with error 42501, permission denied. New projects have had this default since a gradual rollout that began on 30 May. Direct Postgres connections aren't affected.

What stays the same

Existing tables keep their current grants and stay reachable. RLS works as before: grants decide whether a role can reach a table, and policies decide which rows it sees. So a table with RLS off that is already granted to anon may still be readable with your public anon key, and a policy that lets one signed-in user read another's rows is unchanged too. The change covers default privileges in public; other schemas keep their current defaults.

What anon and authenticated can reach today

select c.relname as object,
       case c.relkind when 'v' then 'view' when 'm' then 'materialized view'
                      when 'f' then 'foreign table' else 'table' end as kind,
       r.rolname as role,
       concat_ws(', ',
         case when has_any_column_privilege(r.oid, c.oid, 'select') then 'select' end,
         case when has_any_column_privilege(r.oid, c.oid, 'insert') then 'insert' end,
         case when has_any_column_privilege(r.oid, c.oid, 'update') then 'update' end,
         case when has_table_privilege(r.oid, c.oid, 'delete')      then 'delete' end
       ) as can,
       case when c.relkind in ('r', 'p') then c.relrowsecurity::text
            else 'n/a' end as rls_on
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
join pg_roles r on r.rolname in ('anon', 'authenticated')
where n.nspname = 'public'
  and c.relkind in ('r', 'p', 'v', 'm', 'f')
  and has_schema_privilege(r.oid, n.oid, 'usage')
  and (has_any_column_privilege(r.oid, c.oid, 'select, insert, update')
       or has_table_privilege(r.oid, c.oid, 'delete'))
order by c.relname, r.rolname;

How to read the output

Each row is something to review, not a verdict. rls_on = false means that role may read or change any row it has a grant for. n/a marks views and materialized views: RLS doesn't apply to materialized views, and views without security_invoker = true run with the owner's rights. Column-level grants are included. If a role shouldn't reach an object at all, revoke all on table public.your_table from anon, authenticated; (try it on a non-production copy first).

Adding a table after 30 Oct

Put the grant, RLS and policies in the same migration:

grant select on public.your_table to authenticated;
alter table public.your_table enable row level security;
create policy "Owners read their rows" on public.your_table
  for select to authenticated using ( (select auth.uid()) = user_id );

If a tool hits 42501, a bulk grant ... on all tables in schema public clears the error but also re-grants tables you meant to keep private.

Limits

This is a read-only catalog query. It checks the public schema only, lists grants rather than testing your live app or API, and doesn't flag broad policies such as using (true). A clean result doesn't show there are no issues. Run it only on a database you own or are authorised to access.

Sources: Supabase, "Breaking Change: Tables not exposed to Data and GraphQL API automatically" (supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically); Supabase docs, "Securing your API"; PostgreSQL docs, "System Information Functions".

For tables without RLS, using (true) policies and views without security_invoker, the free self-check runs those checks in one read-only SELECT: https://github.com/nightshiftscan/supabase-rls-self-check (Apache-2.0)

DEV Community