Home / RLS / Fix PGRST205: Could not find the table
Supabase · Error fix
Fix PGRST205: Could not find the table in the schema cache
The Data API doesn't know that table. Check the name and schema first (the hint often suggests the right one), make sure the schema is in the API's exposed schemas, and reload the cache with notify pgrst, 'reload schema'. Then grant the table, or the next error is 42501.
01 What the error says
response
{
"code": "PGRST205",
"message": "Could not find the table 'public.order' in the schema cache",
"hint": "Perhaps you meant the table 'public.orders'"
}
The Data API (PostgREST) keeps a cache of the tables it can serve. HTTP 404 with PGRST205 means the table you asked for isn't in it. This is a different problem from RLS or grants: the request never reached the table.
02 The three causes
Wrong name or schema
A typo, a singular/plural mismatch, or a table that lives in another schema. Read the hint: it suggests the closest match.
The schema isn't exposed
Only schemas listed in the Data API settings (exposed schemas) are served. A table in app needs that schema added there, and the client must ask for it: supabase.schema('app').from('orders').
A stale cache
The table was just created or renamed and the cache hasn't caught up.
03 Reload the schema cache
SQL editor
notify pgrst, 'reload schema';
04 Right after: grants and RLS
Once the API finds the table, the role still needs privileges. Without them the error changes to permission denied for schema app or permission denied for table orders (42501). Set it up in one migration, with RLS on:
migration.sql
grant usage on schema app to authenticated; alter table app.orders enable row level security; create policy "owner reads" on app.orders for select to authenticated using (user_id = (select auth.uid())); grant select on app.orders to authenticated;
Exposing a schema makes every table in it reachable through the API, so each one needs RLS and only the grants it should have. More on the 42501 that follows.
Catch this before it ships
airlock-rls is a CI gate that fails your build when a table ships exposed or a policy is permissive: the same class of bug, caught in CI against a database with your migrations applied, before it reaches prod.
Or start from nextjs-supabase-starter : auth + a table with RLS + an isolation test, so you start from a pattern that's already sealed.
Grab the Supabase RLS cheat sheet
The golden rules, the footguns that leak in prod, correct policy snippets, and the isolation test — on one page.
FAQ
I reloaded the cache and still get PGRST205. Why?
Then it's the name or the schema. Check the hint in the response, and confirm the schema is in the exposed schemas list and that the client calls .schema() for non-public schemas.
Should I expose a private schema to fix it?
Only if the API should serve its tables. Exposing a schema makes all of its tables reachable, so keep helper functions and internal tables in a schema that stays unexposed.