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

> Fix "Could not find the table in the schema cache" and similar errors after a schema change by reloading PostgREST's schema cache on your SupaHost project.

Source: https://supahost.app/kb/postgrest-schema-cache · Updated 2026-11-11

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:

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

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

```json
{"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:

   ```sql
   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:

   ```sql
   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):

   ```sql
   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](/kb/pgrst106-schema-not-exposed).

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](/docs/api/exposed-schemas)
- [Generating TypeScript types](/docs/api/generating-types)
- [PGRST002: Could not query the database for the schema cache](/kb/pgrst002-schema-cache)
- [SQL migrations](/docs/database/migrations)