The Canary Check #001: Supabase stops auto-exposing new tables on Oct 30

One finding, one fix, before you ship.

Hi, this is The Canary Check: one finding, one fix, before you ship.

Finding: the Oct 30 change, and the wrong way to "fix" it

On October 30, 2026, Supabase applies a new default to every existing project: new tables in public won't be reachable through the Data API (supabase-js, REST, GraphQL) until you add an explicit GRANT. Existing tables keep their grants. RLS doesn't change.

When an AI editor creates a table after that date, your app will hit:

42501 permission denied for table your_table

The tempting fix is grant ... on all tables in schema public to anon, authenticated. Don't do that. On a project with any table missing RLS, or with a using (true) write policy, it opens the data to everyone.

Do this instead. Ship grants, RLS and policies together:

grant select, insert, update, delete on public.your_table to authenticated;
alter table public.your_table enable row level security;
create policy "own rows" on public.your_table for select
  to authenticated using ((select auth.uid()) = user_id);

Only grant anon if signed-out visitors really need to read that table.

Check: Security Advisor flags affected tables until the 30th. Full guide: https://prodcanary.com/guides/supabase-tables-not-exposed-data-api-oct-30-2026/ Source: https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically

News

Supabase is also deprecating the legacy anon and service_role keys by the end of 2026 in favour of sb_publishable_... and sb_secret_... keys. Plan the swap now. (https://supabase.com/docs/guides/api/api-keys)

Tip

Add this line to your AI editor's project rules: *"Every new Supabase table must include explicit GRANTs, enable row level security, and one policy per operation in the same migration."*

Run a free scan of your own project zip: https://prodcanary.com/#scan