PostgREST · PGRST205
Could not find the table in the schema cache (PGRST205) — Supabase
Luca Urti
Could not find the table 'public.x' in the schema cache
Why does Supabase say my table is not in the schema cache?
PostgREST keeps an in-memory picture of the database so it does not have to inspect the catalogue on every request, and this error means the table is not in that picture. There are two reasons and they need different fixes: either the table was created after the cache was built and no reload was signalled — common right after a migration — or the table exists in a schema that is not in the exposed list, in which case reloading will change nothing because PostgREST is not meant to see it. A typo in the table name produces the same message, so confirm the object exists before assuming a cache problem.
One query tells you which case you are in
If the table shows up in pg_tables and its schema is public, it is a cache problem and a reload fixes it. If it shows up under another schema, the schema is not exposed and the fix is either to move the table or to expose the schema deliberately — and exposing a schema is a decision, not a formality, because it makes everything inside it reachable with the anon key.
Before you expose a second schema
Schemas created for internal state — audit trails, billing records, job queues, anything a background worker owns — are usually kept out of the API on purpose, and an AI tool that hits this error while generating a client call will frequently suggest adding the schema to the exposed list as the fix. Every table in it becomes addressable at that moment, with only RLS in the way, and internal schemas are precisely the ones nobody wrote policies for because nothing was supposed to reach them.
The fix
diagnose, then reload
-- Does it exist, and where? select schemaname, tablename, rowsecurity from pg_tables where tablename = 'invoices'; -- Case 1: it is in public and the cache is stale. notify pgrst, 'reload schema'; -- Case 2: it is in another schema. Moving it into public means it is -- reachable with the anon key, so enable RLS in the same migration. -- alter table internal.invoices set schema public; -- alter table public.invoices enable row level security;
The fix that works and costs you the database
Adding an internal schema to the project's exposed-schema setting makes the error go away for one table and puts every other table in that schema on the API at the same time. Those are the tables least likely to have RLS, because they were never meant to be reachable — which makes this the rare configuration change that can expose a dozen tables in a single click.
Whether the trap is already in your repo is a question you can answer
Sentris reads the SQL and the client code, so it reports the shortcut above where it was actually taken — a service_role key in a browser bundle, a policy that is using (true), a table with RLS switched off. A scan needs no account and no card. How often it is wrong is measured and published.