Supabase Table Not Showing Up in API (2026): The Grants Fix

You created a table in the Supabase dashboard, called .from('orders').select(), and got back nothing. No rows, no obvious crash, just an empty result and an error object your code probably swallowed. The table is right there in the table editor.

Two different failures produce that symptom, and they have opposite fixes. Log the actual error before you touch anything.

Read the error code first

The Supabase JavaScript client returns errors instead of throwing them, which is why so many people see "no data" and never see the reason. Print the whole object.

const { data, error } = await supabase.from('orders').select('*')
if (error) console.error(JSON.stringify(error, null, 2))

You'll get one of two shapes.

A grant is missing. Supabase documents this exact response:

{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

PostgREST cannot see the table at all:

{
  "code": "PGRST205",
  "message": "Could not find the table 'public.your_table' in the schema cache"
}

Everything below assumes 42501. If you got PGRST205, skip to the PGRST205 section.

What Supabase actually changed

Until this year, creating a table in public silently handed select, insert, update and delete to anon, authenticated and service_role. That default is why so many vibe-coded apps ship with an open database: the table was reachable the moment it existed, and nothing asked you to confirm that.

Supabase is reversing it. The rollout:

The toggle is the "Automatically expose new tables" checkbox on the project creation screen. Unchecked means you're on the new behaviour.

The reason given is that explicit grants are reviewable and greppable, and that anon and authenticated need different privileges anyway. That's true, and it's also the first Supabase default change in a while that makes the insecure configuration harder to reach by accident.

Audit before you grant

Before adding a grant, find out what your project already looks like. Paste this into the SQL editor. It lists every table in public, whether row level security is on, and which Data API roles hold which privileges.

select
  c.relname as table_name,
  c.relrowsecurity as rls_enabled,
  coalesce(
    string_agg(
      distinct g.grantee || ':' || g.privilege_type,
      ', ' order by g.grantee || ':' || g.privilege_type
    ),
    '(none)'
  ) as data_api_grants
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
left join information_schema.role_table_grants g
  on g.table_schema = n.nspname
 and g.table_name = c.relname
 and g.grantee in ('anon', 'authenticated')
where n.nspname = 'public'
  and c.relkind in ('r', 'p')
group by c.relname, c.relrowsecurity
order by c.relrowsecurity, c.relname;

Read the top of the result, not the bottom. The ordering puts rls_enabled = false first on purpose.

A row with rls_enabled = false and anything other than (none) in the grants column is readable, and possibly writable, by anyone who has your anon key. That key is compiled into your JavaScript bundle. It is not a secret.

This is the pattern our scanner flags on Supabase-backed apps constantly. The table that's broken today is rarely the dangerous one. The dangerous one has been working fine for months.

Fix the missing grant

Do these in order. The order matters, because grants take effect immediately and RLS does not exist until you enable it.

alter table public.orders enable row level security;

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

-- only if this data is genuinely public
grant select on public.orders to anon;

-- the logged-in path
grant select, insert, update, delete on public.orders to authenticated;

-- your backend and edge functions
grant select, insert, update, delete on public.orders to service_role;

grant usage, select on all sequences in schema public to authenticated;

curl -s "https://YOUR_PROJECT.supabase.co/rest/v1/orders?select=*" \
  -H "apikey: YOUR_ANON_KEY" | head -20

The fix that breaks everything

Search this error and you will land on some version of this:

grant all on all tables in schema public to anon, authenticated;

It works. Your table appears in the API immediately. It also hands anonymous visitors select, insert, update and delete on every table in your database, including the ones you never intended to expose, plus every table you create later if you pair it with alter default privileges.

If RLS is off on any of those tables, and on a vibe-coded project it usually is on at least one, that command is a full database exposure. Supabase's own security docs put it plainly: tables exposed through the Data API without RLS can be accessed by any role with matching grants.

Grants and RLS are separate layers, and people conflate them constantly. A grant decides whether a role can touch the table at all. RLS decides which rows it gets back. When the grant is missing, Postgres rejects the query before RLS is ever consulted, which is why "permission denied" shows up even on a table with perfectly good policies.

PGRST205 is a different problem

If your error code is PGRST205, no amount of granting will help. PostgREST builds a cache of the schemas it's told to expose, and your table is not in it. Three causes, in the order they're worth checking:

The schema isn't exposed. Tables in a custom schema like app or billing need that schema added under Project Settings > API > Exposed schemas. public is exposed by default; nothing else is.

The cache is stale. PostgREST reloads on DDL changes, but a table created through an external connection or during a busy migration can miss the signal. Force it:

notify pgrst, 'reload schema';

The name is wrong. Postgres folds unquoted identifiers to lowercase. A table created as "Orders" with quotes is not the same relation as orders, and .from('orders') will never find it. Check the exact relname in the audit query above.

Before October 30

Two things worth doing now rather than the week it lands.

First, make grants part of your migrations. If you use the Supabase CLI, the create-table migration should carry the enable row level security, the policy, and the grants in one file. A table definition that doesn't say who can read it is incomplete, and after October 30 it'll be visibly incomplete instead of silently permissive.

Second, run the audit query and deal with what it shows. Every project that predates this change was built under the old default, which means tables got exposed by creation rather than by decision. The change doesn't clean those up for you. Nothing does.