Guide Supabase

My app stopped saving data after Oct 30. What happened?

By the PatchAndShip team Last verified:

Short answer

Your existing tables keep the access they have today. From Oct 30, 2026, Supabase plans to stop giving new tables in the public schema API access automatically, so a new feature that saves into a new table may need a one-line grant first. A 42501 \"permission denied\" error points to a missing grant; an empty list with no error usually points to RLS. If old features stopped too, this is probably not the Oct 30 change.

The short answer

Your existing tables keep the access they have today. Supabase says existing tables keep their current grants and stay reachable [S1]. That doesn't mean they're set up well, only that Oct 30 doesn't change them.

On Oct 30, 2026, Supabase plans to apply a new default to all existing projects: new tables in the public schema will no longer get API access automatically [S1]. In Supabase's words: "Once the change is rolled out to your project, new tables you create in public schema require an explicit opt-in (via a Postgres grant) before the Data API can see them. Existing tables are not affected in your project, they keep their current grants and stay reachable." [S1]

So if your app saves into a table created after the change reaches your project, that table may need a one-line permission (a "grant") first.

If old features stopped too, this is probably not the Oct 30 change.

Is this my problem? A 2-minute check

Did this start with a new feature or a new table?

If yes, that's the likely cause. If old features broke too, it's probably something else. See Not this?.

Find the real error message

Open your browser's developer tools (right-click, Inspect) and check the Console or Network tab, then click save again.

  • Look for "permission denied for table" or code 42501. That means a missing grant, so go to the fix. Supabase says the error looks like this, with a hint that shows the missing GRANT [S1].
  • No error, but the list stays empty? That's usually RLS filtering rows, not grants. With RLS on and no matching policy, Postgres shows no rows rather than an error [S2]. See I turned on RLS and now my app shows no data.
-- What a missing grant looks like (from Supabase's changelog)
-- "code": "42501"
-- "message": "permission denied for table your_table"

Or ask your AI tool to find it

Paste this in:

"When I click save on [feature], it doesn't save. Please check the browser console and Supabase response for this request and tell me the exact error code and message. Don't change any security settings yet."

The fix (pick one)

Option A: Ask Lovable or Bolt to add the grant

Paste this in:

"Starting Oct 30, 2026, Supabase will no longer expose new tables in the public schema to the API automatically. For the table [table_name], write a migration that grants only the access my app needs to the authenticated role, makes sure row level security is enabled, and adds policies so each user can only read and change their own rows. Show me the SQL before running it."

Option B: Run it yourself in the SQL Editor

In the Supabase dashboard, open the SQL Editor. This example is for a table where signed-in users save their own rows. It follows the "What to do" example in Supabase's changelog [S1]. Replace your_table with your table's name. Turn RLS on first, then grant.

alter table public.your_table enable row level security;
grant select, insert, update, delete on public.your_table to authenticated;

Then add policies so each user only reads and changes their own rows. Make sure RLS is enabled and has policies before you call it done. Supabase says to treat the grant, RLS and policies "as a unit" [S1]. Our 42501 after Oct 30 guide (step 3) and Supabase RLS policy examples have the policy SQL.

  • Only add grant select on public.your_table to anon; if signed-out visitors should see this data. Keep RLS on with a read-only policy if you do.
  • A grant on a table with RLS off opens every row to that role. Turn RLS on in the same step.
  • If your AI tool deletes a table and creates it again, treat it as a new table: it may need its grant again. Privileges belong to the table itself, so a new table doesn't inherit the old one's [S4].

If your table uses an auto-numbered id

If the new table's id column is a serial or bigserial (a number that counts up by itself), the insert also uses a sequence behind the scenes. Postgres needs USAGE on that sequence to hand out the next number [S3], and Supabase's SQL for the new default also revokes the default grants on new sequences in public [S1]. If saving still fails after the table grant, find the sequence name and grant it to the role that inserts:

select pg_get_serial_sequence('public.your_table', 'id');
-- usually returns public.your_table_id_seq
grant usage on sequence public.your_table_id_seq to authenticated;

Tables with a uuid id don't need this step.

Check it worked

  1. Save something as user A.
  2. Sign in as user B and make sure B can't see A's row.
  3. Sign out and try again. A private table should show nothing.

Please avoid these shortcuts

Granting everything on all tables, or switching RLS off, makes the app "just work", but it can open every table to anyone with your public key. Grant only what this one table needs. See Table publicly accessible.

Not this?

If old features broke too, it's probably not the Oct 30 change. Try I turned on RLS and now my app shows no data, or read what the Oct 30 grants change does.

Want a second pair of eyes?

Want a quick look at your app's public side first? Our free check reads your homepage, a few of its JavaScript files, headers and storage links in the browser. It doesn't log in, query your database or test grants or RLS, so it can't tell you about this error. If you'd rather not touch the SQL yourself, we can look at it for you: see what to do about the Oct 30 change.

A person reviews every change we make. Our service isn't a penetration test or a security guarantee.

Sources