Guide Supabase

I made a new table and my app can't see it

By the PatchAndShip team Last verified:

Short answer

The Table Editor shows every table, but your app goes through the Data API, which only sees tables it has been granted. From Oct 30, 2026, Supabase plans to stop granting new tables in the public schema automatically. Add a grant for just that table, keep RLS on with policies, and tell your AI tool to include grants with every new table.

Why you can see the table but your app can't

The Table Editor shows every table. Your app talks to the Data API, which only sees tables its roles have been granted. On Oct 30, 2026, Supabase plans to apply this to all existing projects: new tables in public won't be granted automatically [S1]. Supabase says: "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]

It doesn't matter how the table was made. "Without a grant, the API cannot see the table, regardless of how you created it (SQL editor, migrations, Management API, MCP, CLI, or an AI coding tool)." [S1]

There are two layers, in plain words:

  • A grant decides if your app can reach the table at all.
  • RLS decides which rows each user sees.

Supabase puts it the same way: grants "control whether a role can access a table at all, while RLS controls which rows that role can see" [S1]. Your app uses the anon role for signed-out visitors and authenticated for signed-in users [S5].

Which one is it?

  • Error "permission denied for table" or code 42501 means a missing grant. Keep reading, or see the 42501 after Oct 30 guide.
  • An empty list with no error is usually RLS. See I turned on RLS and now my app shows no data.
  • Tip: Supabase says the Data API exposure badge in the Table Editor and the Security Advisor list the tables worth reviewing [S1].

Fix this table

Ask your AI tool

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."

Or run the SQL yourself in the SQL Editor

Here's a read-only example for a list your signed-in users view. 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 on public.your_table to authenticated;

Add insert, update or delete to the grant only if the app writes to the table. Make sure RLS is enabled and has policies. Step 3 of the 42501 guide and Supabase RLS policy examples show how. Only grant to anon if signed-out visitors are meant to see the table, and keep RLS on if you do.

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.

Stop this from happening with every new feature

Add a standing instruction to your AI tool

Use the paste-in text from our grants guide, What should I tell Lovable, Bolt, Replit or Cursor?, and save it where your tool keeps project instructions:

  • Lovable: Project settings > Instructions (project knowledge) [S6]
  • Bolt: Project settings > Knowledge [S7]
  • Cursor: a project rule in .cursor/rules, or an AGENTS.md file [S8]
  • Other tools: their saved project instructions

The Supabase agent skill

Supabase's changelog suggests that if an AI tool creates your tables, you "update its system prompt or adopt the Supabase agent skill, which includes the grants step" [S1]. The changelog links to Supabase's post on agent skills [S9].

Please don't bulk-grant everything

Supabase's changelog does show a bulk grant ... on all tables in schema public. It sits in the FAQ as a rollback for people who opted in early and want the old behavior back, not as a fix for one table [S1]. It grants every table in public to the API roles, including tables you meant to keep private. For one new table, grant only that table. See Table publicly accessible.

The change doesn't touch tables in storage, auth, realtime or custom schemas [S1].

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 Fix Supabase RLS in a Lovable app.

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