Hosted Data API Fails When PostgREST Uses Non-Existent Schemas After Dashboard Exposed-Schema Changes

The Supabase Dashboard's management of PostgREST configuration does not always synchronize the exposed-schemas setting with the running PostgREST instance. PostgREST may retain a default 'public' schema or previously configured schemas in db-schemas even after they have been removed from the Dashboard or dropped from the database. When PostgREST attempts to load its schema cache, it fails because those schemas no longer exist.

1. Have a hosted Supabase project with custom API schemas only and no 'public' schema. 2. Drop a previously exposed schema (e.g., 'api') as part of a migration. 3. In Dashboard, go to Integrations > Data API > Settings > Exposed schemas and save a list containing only the custom schemas. 4. Optionally toggle the Data API off/on or reset the schema list. 5. Observe PostgREST logs still showing db-schemas including the dropped schema or 'public'. 6. Data API calls return 500 with PGRST002 because PostgREST cannot load schema cache.

This creates a database-level override that may diverge from future Dashboard settings. Any later changes to Exposed schemas in the Dashboard will not take effect until the override is removed or updated. To rollback, run: ALTER ROLE authenticator RESET pgrst.db_schemas; ALTER ROLE authenticator RESET pgrst.db_extra_search_path; NOTIFY pgrst, 'reload config';. Ensure the role name is correct for the project and that the SQL user has sufficient privileges. In multi-tenant or pooled environments, consider potential impact on other connections.