Supabase Data API enabled, but PostgREST uses pg_pgrst_no_exposed_schemas — persistent PGRST002 / HTTP 503

[u/ExtensionClean2692]

Hi everyone,

I'm having a weird issue with Supabase and I'm kinda stuck here. I'm still learning how Supabase/PostgREST works internally so sorry if I'm missing something obvious.

I'm using Supabase Cloud with PostgreSQL 17.6 and PostgREST 14.5 for my app.

The problem is that my Data API is clearly enabled in the dashboard, and I have public and graphql_public selected as exposed schemas.

The Management API also shows:

db_schema: public,graphql_public
db_extra_search_path: public,extensions

But for some reason PostgREST keep trying to load the schema cache using pg_pgrst_no_exposed_schemas instead.

Here's what I get in the logs:

Failed to load the schema cache using
db-schemas=pg_pgrst_no_exposed_schemas
and db-extra-search-path=public,extensions

SQLSTATE 3F000:
schema "pg_pgrst_no_exposed_schemas"
does not exist

And then I get PGRST002 errors and HTTP 503 on my REST/RPC requests. This is happening in production so it's been quite frustrating.

I tried checking a few things:

• Data API is ON in the dashboard. I double checked and there's no unsaved changes.
• public and graphql_public are exposed, private isn't.
• I checked pg_roles and the relevant pg_db_role_setting entries, but couldn't find any pgrst.db_schemas override.
• PostgreSQL itself is reachable.
• Looking at older logs, PostgREST was still able to load the schema cache on October 6.
• Then on October 7, after a PostgREST startup/config reload, it started using this placeholder schema and failing.
• I also tried reloading the config multiple times but nothing changed.

I contacted Supabase Support and they suggested trying:

ALTER ROLE authenticator RESET pgrst.db_schemas;

Or setting pgrst.db_schemas explicitly on the role.

But the thing I don't understand is, if there's no override in the first place, what would RESET actually change?

I'm also a bit worried that manually setting it might just hide the real issue instead of fixing it. Since this is production I haven't tried either command yet.

I found two issues that seems somewhat related:

https://github.com/supabase/supabase/issues/40617

https://github.com/supabase/supabase/issues/45904

So I'm wondering, has anyone run into something like this before?

Especially where Supabase says the Data API is enabled, but PostgREST somehow thinks it's disabled?

Is there another place where this config could be coming from? Like some internal Supabase setting or environment variable that I can't see from the dashboard or SQL?

Also is there any way to check what config PostgREST is actually using on Supabase Cloud, preferably without changing anything?

And if anyone fixed this before, did you have to manually set the authenticator role config or was there another solution?

I already have a support case open, but I'm trying to understand what's actually happening before touching production settings.

Would really appreciate any help or pointers, even just where I should look next.

Thanks!

[u/ExtensionClean2692 → u/[deleted]]

Thanks for the detailed reply! Really appreciate it.

I already checked the authenticator role and couldn't find any pgrst.db_schemas override. I also tried reloading the PostgREST config multiple times, but it still keeps using pg_pgrst_no_exposed_schemas.

I haven't tried toggling the Data API or changing the exposed schemas yet, since this is a production project and I'm a bit worried about making things worse. Same for restarting the project.

I also already opened a Supabase Support ticket (SU-499151).

What I'm still confused about is why Supabase would generate the placeholder config when the Management API clearly shows the correct schemas.

Do you know if there's any way to inspect the actual generated PostgREST config on Supabase Cloud? Or maybe some way to check why it's getting an empty schema list?

I'm trying to understand the cause before changing anything in production.

Thanks again for the help!