Data API (PostgREST) returning 100% errors — restart didn't fix it (ticket SU-535416)

[mathheusquintela-design]

Ticket SU-535416 (still open, 2-3 business day queue).

Our project's Data API (/rest/v1/*) has been failing on ~100% of requests
since [data/hora do início]. Support already restarted PostgREST on this
ticket, but it did not resolve it — errors just changed from 504 to 503,
still ~100% failure.

Confirmed it's isolated to PostgREST, not the Postgres engine itself:

• Direct SQL queries via the SQL editor run instantly, no issue.
• pg_cron jobs keep running fine every minute.
• /auth/v1/health returns 200.
• /rest/v1/* returns 100% failures.

The project's own Health Advisor confirms this right now:
"log_data_api_error_rate_high" — Data API 100% of requests failing.

This is taking down our production site. Posting here since the support
queue is slow and this is a confirmed outage, not a one-off error.

[colinmccallion-lang]

Since SQL and auth work and only /rest/v1 fails, PostgREST is most likely failing on startup while it loads your schema. That's usually caused by something in the database, not the platform. Worth checking while you wait on the ticket:

1. Recent migrations. A broken view or function in an exposed schema (often a view pointing at a dropped column, or a function with an invalid return type) can stop the schema cache from loading. Run notify pgrst, 'reload schema'; in the SQL editor, then check Logs > PostgREST for the actual error message.
2. Settings > API > Exposed schemas. If a listed schema was dropped or renamed, PostgREST can't start.
3. The authenticator role. If a migration changed its password, statement_timeout or grants, PostgREST can't connect even though Postgres is fine.
4. Connections. Check whether you're at your connection limit (select count(*) from pg_stat_activity;). pg_cron jobs plus an app pool can starve PostgREST.

The PostgREST log line will usually name the failing object. If you paste it here with keys removed, people can point to the fix.