Supabase stops auto-exposing new tables on 30 October 2026

Supabase published the breaking change on 28 April 2026. New projects stopped exposing new public tables by default on 30 May 2026. On 30 October 2026 the same setting is applied to existing projects. The source is their changelog, Tables not exposed to Data and GraphQL API automatically.

Until then, a new table in public was reachable from the Data API because Postgres granted select, insert, update, and delete to anon, authenticated, and service_role. After the change, a new table exists but the API cannot see it until you grant the role you actually want.

Existing tables keep the grants they already have. Altering a table does not strip them. A project with no flagged tables today still breaks the first time someone creates a new one in public and expects supabase-js to read it.

PostgREST answers a missing grant with 42501 and permission denied for table your_table. The hint names the statement, for example GRANT SELECT ON public.your_table TO anon. Supabase documents that response in the changelog and in Database API 42501 errors. The failure happens before any row level security policy runs.

This is the shape Supabase shows: a grant for the role, RLS enabled, then a policy. Rename the table and the user column. anon gets read only here. service_role bypasses RLS, so keep that key on the server and grant it only in server migrations, not in the browser.

-- Rename your_table and user_id. Do not disable row level security.
grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to authenticated;

alter table public.your_table enable row level security;

create policy "users can read their own rows"
on public.your_table
for select
to authenticated
using (auth.uid() = user_id);

If an insert fails because the identity column’s sequence is not granted, add grant usage, select on sequence public.your_table_id_seq to authenticated. That is a sequence grant, not a reason to turn RLS off.

The free check and the Launch Report do not connect to your database and do not test policies. If the public page contains a Supabase URL, the report says so and the paid report includes this SQL to paste. You still run it yourself in the SQL editor. A weekly Monitor rescan repeats the same passive check. It will not notice a missing grant.