PostgREST not seeing new tables, columns or functions (schema cache)

You added a table, column or function, but the Data API acts as if it isn't there. The cause is almost always PostgREST's schema cache, and the fix takes one SQL statement.

What you see

One of these responses from /rest/v1/, usually right after a migration:

{"code":"PGRST205","details":null,"hint":null,"message":"Could not find the table 'public.recipes' in the schema cache"}

{"code":"PGRST204","details":null,"hint":null,"message":"Could not find the 'prep_minutes' column of 'recipes' in the schema cache"}

{"code":"PGRST202","details":"...","hint":"...","message":"Could not find the function public.search_recipes(term) in the schema cache"}

In supabase-js the same text arrives in error.message. A relationship you just added can also fail with PGRST200 ("Could not find a relationship between ... in the schema cache").

Why it happens

PostgREST (v14 on SupaHost) doesn't read the Postgres catalog on every request. It builds a cache of tables, columns, functions and foreign keys when it starts, and rebuilds it when it receives a reload schema notification.

Supabase's Postgres image ships event triggers (pgrst_ddl_watch and pgrst_drop_watch) that send that notification after DDL, so most changes show up within a second. You see stale results when:

• the notification was sent while PostgREST was reconnecting, so it missed it;
• the event triggers were disabled or dropped;
• the object really doesn't match what you're calling: a typo, a different schema, or a function called with argument names that differ from its parameter names.

How to fix it

1. Open the SQL editor for the affected project and run:

   notify pgrst, 'reload schema';
   

   Retry the request. If it works now, you're done.

2. If it still fails, check the object exists where you think it does:

   select table_schema, table_name
   from information_schema.tables
   where table_name = 'recipes';
   
   select p.proname, pg_get_function_arguments(p.oid)
   from pg_proc p join pg_namespace n on n.oid = p.pronamespace
   where n.nspname = 'public' and p.proname = 'search_recipes';
   

   For RPC, the JSON keys you pass to supabase.rpc('search_recipes', { term: 'pie' }) must match the parameter names exactly.

3. Check the event triggers are present and enabled (O means enabled):

   select evtname, evtenabled from pg_event_trigger where evtname like 'pgrst%';
   

4. If the table lives in a schema other than public, the cache isn't the problem. See PGRST106.

5. If you generate TypeScript types, regenerate them too. Old types make the editor complain about columns the API already accepts.

On SupaHost

Each project is its own Postgres database, and each has its own PostgREST. Run the notify in the project that's failing: open Studio from that project in the dashboard, or use the MCP execute_sql tool with a token scoped to that project. Sending it in another project does nothing for this one.

Migrations applied with the MCP apply_migration tool are ordinary DDL, so the event triggers fire for them as well.

Related

• Exposed schemas
• Generating TypeScript types
• PGRST002: Could not query the database for the schema cache
• SQL migrations