Are custom PostgreSQL role passwords or SCRAM verifiers exposed in Supabase logs?

[lh3750-ops]

Hi Supabase community,
I’m preparing a security-sensitive Node.js application using Supabase only as hosted PostgreSQL. We are not using Supabase Auth or the Data API.
We need to create a dedicated least-privilege PostgreSQL LOGIN role for the application runtime.
The intended model is:

• postgres / migration identity — initialization only
• dating_runtime — NOLOGIN, restricted application role
• dating_beta_api — dedicated LOGIN, no administrative privileges
• runtime transactions use SET LOCAL ROLE dating_runtime
• tenant tables use forced PostgreSQL RLS
  The remaining concern is secure credential provisioning.
  We do not want either the plaintext runtime password or a reusable SCRAM-SHA-256 verifier to appear in PostgreSQL logs, Supabase Log Explorer, platform/audit logs, or other retained telemetry.
  For example, if initialization executes:
  CREATE ROLE dating_beta_api
  LOGIN
  PASSWORD 'SCRAM-SHA-256$...';

my understanding is that PostgreSQL statement/error logging could potentially record the credential-bearing SQL.
One possible approach would be a controlled administrator session such as:
BEGIN;
SET LOCAL log_statement = 'none';
CREATE ROLE dating_beta_api
LOGIN
PASSWORD 'SCRAM-SHA-256$...';
-- restricted grants here
COMMIT;

Before implementing this, I would appreciate guidance on the Supabase-supported approach:

1. Can CREATE ROLE, CREATE USER, or ALTER ROLE ... PASSWORD statements appear in Supabase/PostgreSQL logs with the password or SCRAM verifier intact?
2. Does Supabase automatically redact plaintext PostgreSQL role passwords or SCRAM verifiers from native statement/error logs?
3. Can the project postgres administrator safely use SET LOCAL log_statement = 'none' for the credential-provisioning transaction?
4. If the credential-bearing statement fails, could log_min_error_statement still log the complete failed statement and expose the password/verifier?
5. Is there a recommended Supabase mechanism for creating a custom least-privilege PostgreSQL LOGIN without putting password-equivalent material into retained SQL logs?
6. Is there a Dashboard/API credential-provisioning method for custom PostgreSQL roles that avoids password-bearing SQL entirely?
   We have not executed the credential creation yet and are looking for the safest supported pattern before doing so.
   Thanks for any guidance, especially from anyone who has implemented custom least-privilege PostgreSQL roles on Supabase.

[DigitalA7]

I can answer the PostgreSQL side from a test; the Supabase-specific retention and redaction questions (2, and the platform part of 5 and 6) need someone from the team, and I would not assume redaction without their confirmation.

What stock PostgreSQL does (checked on 16.15):

1. Yes, the statement can be logged in full. With log_statement = 'ddl' (or mod/all), CREATE ROLE ... PASSWORD '...' is written to the server log exactly as sent. Core PostgreSQL does not redact it; the CREATE ROLE docs warn that the password "might also be logged in the client's command history or the server log".
2. SET LOCAL log_statement = 'none' is not available to a non-superuser. It fails with permission denied to set parameter "log_statement" unless the role has been granted SET on that parameter. On your project, check with select has_parameter_privilege('postgres', 'log_statement', 'SET'); and show log_statement;.
3. Yes, a failed statement is a separate path. With log_statement = 'none' a successful CREATE ROLE left nothing in my log, but one that failed (role already existed) was logged in full on the STATEMENT: line, because log_min_error_statement defaults to error. So silencing log_statement alone does not cover the failure case.

A pattern that limits the exposure whatever the log settings are:

• Create the role with no secret in the statement: CREATE ROLE dating_beta_api LOGIN; followed by your grants. Nothing sensitive can be logged, and this is the step most likely to fail.
• Set the password separately from psql with \password dating_beta_api. psql computes the SCRAM-SHA-256 verifier on the client and sends ALTER USER ... PASSWORD 'SCRAM-SHA-256$...', so the plaintext never reaches the server or its logs. The verifier itself can still be logged if log_statement covers DDL or the statement errors.
• Treat the verifier as sensitive but not as the password: it cannot be replayed to log in, but anyone who obtains it can test password guesses offline. With a long random password (generated, not chosen) that attack is not practical, which is what makes a logged verifier tolerable where a logged plaintext is not.
• Check afterwards with select rolpassword like 'SCRAM-SHA-256$%' from pg_authid where rolname = 'dating_beta_api'; if your role may read pg_authid; otherwise a test login is enough.

What I did not verify: Supabase's default log_statement on hosted projects, whether Log Explorer or other retained telemetry redacts these statements, and whether the Dashboard offers a way to create a custom login role without SQL. Those are the parts to get from Supabase directly.

[cekuu35]

I can fill most of the Supabase-specific gaps from the current docs — with one correction to the threat model that matters more than any of the defaults: the error path leaks even when statement logging is off.

What the Supabase docs establish

1. Statement logging is opt-in, via pgAudit. By default, Postgres logs on a hosted project capture "database activity and errors" — statement classes are not recorded until you enable pgAudit and select a scope. So the happy path of CREATE ROLE ... PASSWORD '...' does not land in Log Explorer on a default project.

2. The failure path is a different story. An erroring statement is logged with its full text on the STATEMENT: line (stock Postgres log_min_error_statement defaults to error, and that behavior isn't overridden on hosted). Supabase's own Postgres log surface shows errors by default — see the SQLSTATE filtering examples. Concretely: a CREATE ROLE that fails (duplicate role, syntax, grant typo in the same transaction) writes the entire statement — password included — into postgres_logs, where it's searchable in Log Explorer by anyone with project access, subject to plan-based retention, and exported anywhere a log drain points.

3. No redaction is documented — quite the opposite. The statement-logging guide explicitly warns that "recorded statements and messages can contain sensitive values." I would treat any credential-bearing statement as retained telemetry by policy, independent of what the platform does.

4. If pgAudit is on, scope it away from your provisioning session. pgAudit on Supabase supports session and role-scoped configuration. If your project (or a teammate) has DDL auditing enabled, run credential provisioning from a connection whose role is outside the audited scope — that's the one lever the platform gives you for keeping secrets out of retained statement logs.

What this changes in practice

The split pattern @DigitalA7 described becomes even more clearly right on hosted:

1. CREATE ROLE dating_beta_api LOGIN; plus all grants — no secret in any statement, so both the happy path and the error path are harmless.
2. Set the password in a statement that cannot error: from a local psql against the project's connection string (direct connection), \password dating_beta_api computes the SCRAM verifier client-side, so the plaintext never leaves your machine. The ALTER ROLE it sends can still end up in logs only if it errors (it shouldn't — the role exists) or if pgAudit DDL is on for that role — hence point 4.
3. Studio-only option, if psql isn't available: compute the SCRAM-SHA-256 verifier yourself offline and ALTER ROLE ... PASSWORD 'SCRAM-SHA-256$...' in the SQL editor — accepting that a failed run would log the verifier (offline-guessable, not replayable; tolerable only with a generated long-random password, as said above).

One genuinely open question for the team, which the docs don't settle: whether SQL executed through the Studio SQL editor / Management API is retained on the platform side separately from postgres_logs (the editor's own history and the platform's query records). The rest above is doc-backed.

---

Small disclosure: I audit Supabase/PostgREST setups for production apps, so I care about exactly this class of question — but the doc references above are the load-bearing part, and everything in them stands on its own.