Reset Database Password fails silently — role "postgres" cannot be altered ("permission denied to alter role")

[joseniltonbomfim40-ai]

The "Reset database password" feature in the Dashboard (Project Settings → Database) reports success and displays a new generated password, but the password is never actually applied — the underlying ALTER USER postgres WITH PASSWORD ... statement executed by the dashboard itself fails server-side with a permission error.

Confirmed via postgres_logs at the exact timestamp of a reset attempt:

2026-09-15T00:34:54.617Z — statement: ALTER USER postgres WITH PASSWORD '{REDACTED}';
-- source: dashboard
-- user: session:0a3b5f20-a6aa-4f5c-a32b-f3f1e31acb42
-- date: 2026-09-15T00:34:53.759Z

2026-09-15T00:34:54.617Z — permission denied to alter role

The comment -- source: dashboard confirms this was triggered by the official "Reset database password" UI action, not a manual SQL Editor query. I also confirmed manually running ALTER USER postgres WITH PASSWORD '...' via the SQL Editor fails identically with "ERROR: 42501: permission denied to alter role — Only superusers can alter privileged roles."

Impact: I'm unable to obtain a working password for the postgres role, which blocks any external Postgres connection (direct or via the Session/Transaction pooler) using database credentials — for example, pg_dump-based backups via GitHub Actions consistently fail with FATAL: password authentication failed for user "postgres" no matter how many times the password is reset through the dashboard, because the reset never actually takes effect.

Request: Please investigate why the postgres role on this project cannot be altered even through the official dashboard flow (which should run with sufficient privilege), and manually apply a working password reset on your end so I can restore working database-credential access.

Thank you.

[cekuu35]

This is a known platform permission boundary, not something you can fix client-side.

Why it fails: On hosted Supabase, postgres is owned by supabase_admin, and the dashboard's reset action runs as a limited session role that (in your project's current state) lacks the grant path to ALTER USER postgres. The UI should surface this failure instead of reporting success — that's a product bug worth reporting via support ticket with your log excerpt (you've already captured the perfect evidence with the postgres_logs line).

Workaround today:

1. Open a support ticket (dashboard → Help) and paste that log excerpt — support can rotate behind the permission boundary; your capture is exactly what they need.
2. If you still have a working connection via the pooler direct connection with the old password stored somewhere (CLI config, Vercel env), rotate it there via a single privileged session.
3. Going forward, don't depend on the postgres superuser for app traffic — create app_user / app_migrator roles with GRANTed privileges and keep the superuser password in a vault; then a broken UI reset never blocks production.
4. After any rotation succeeds, update DATABASE_URL everywhere at once (Vercel, .env, CLI) — a stale copy is the most common "reset didn't work" false alarm.

Free RLS/grants audit queries (catalog-level, read-only): https://github.com/cekuu35/supabase-rls-leak-demo