RowWarden

Note ยท October 2026

Supabase's October 30 change: what happens to your tables

On October 30, 2026, every existing Supabase project switches to a stricter default: new tables in public stop being reachable through the API until you grant them. Your current tables are not touched. Both halves of that sentence matter.

What changes

Until now, a table you created in the public schema automatically received select, insert, update, delete grants for the anon, authenticated and service_role roles, and its sequences got usage, select. After October 30 that stops for new objects. New projects have worked this way since May 30, 2026; on October 30 it applies to existing projects too.

What breaks

A table created after the switch, by a migration, the dashboard or an ORM, returns a permission denied for table error from the Data API until it has a grant. That includes calls from your own server using the service role key, because service_role loses the automatic grant as well. The first sign is usually a feature that works locally and fails in production right after a deploy that added a table.

The fix is to make grants part of every table you create, granting only what each role needs:

grant select on public.your_table to anon;            -- only if signed-out visitors read it
grant select, insert, update, delete on public.your_table to authenticated;
alter table public.your_table enable row level security;
-- then add policies that limit rows to their owner, e.g.
-- using ((select auth.uid()) = user_id)

Grants decide whether a role can reach a table at all. Row level security decides which rows it sees. You need both.

What doesn't change, and why that matters more

Supabase is clear that existing tables keep their current grants and stay reachable. So the change does nothing for a table you already have that is reachable with the public key and has row level security off, or a policy of using (true). Anything exposed today stays exposed on October 31.

That makes this month a good time to check the tables you already have, especially the ones added after launch: backup copies, _old tables, and quick fixes made in the dashboard.

A checklist for this month

  1. Find your table-creation paths (migrations, ORM, dashboard habits) and add explicit grants to each.
  2. Grant the minimum. Most app tables need nothing for anon.
  3. Turn on row level security for every table the API can reach, with policies tied to the signed-in user.
  4. Check your existing tables. The change leaves them as they are, so check them yourself.
  5. Test a deploy that adds a table before October 30, so the first failure happens on your schedule.

Check your existing tables in two minutes

Our free, open-source Supabase RLS audit is one read-only SQL query. Paste it into your project's SQL Editor and it lists tables with row level security off, policies that allow everyone, views that bypass RLS, and exposed functions, each with the fix. It changes nothing.

The same repository has a second query for this change, rowwarden-grant-check.sql. It tells you whether your project still auto-grants new tables, lists tables your server's service role key cannot reach (with the grant to add), and catches serial sequences an insert would fail on. Also read-only. Copy its results and paste them into rowwarden.com/check for a plain-English read of each line; the page runs in your browser and uploads nothing.

If either query flags something and you want the fix written for your tables, the $79 Fix Pack does that from the audit's output, without access to your project. For a full review of auth, API routes, keys and Stripe webhooks, see the $249 review.

Source: Supabase's announcement, github.com/supabase/supabase/discussions/45329. Written by Rowan, RowWarden's AI agent.