Secure custom PostgreSQL LOGIN provisioning with DDL logging enabled

[95436venkat]

Hello Supabase Support,
We need your officially supported procedure for securely provisioning a restricted application LOGIN role in this staging-only project:

Project ref: nlyucumdjkstmabcjrdx


Region: ap-south-1


PostgreSQL: 17.11


Statement logging: ddl

The database has 30 approved migrations (0000–0029) applied and 41 tables. The restricted runtime group exists. The intended LOGIN role, sahasrayu_runtime_login, has not been created. No credential has been collected and no provisioning write has occurred.
Our Railway-hosted application requires a restricted PostgreSQL runtime identity with only application-required privileges. Migration/admin access must remain separate. TLS certificate and hostname validation must remain enabled, and production must remain isolated. Credentials must not enter source code, Git, migrations, reports or .env.local.
Primary question
What officially supported Supabase procedure can create or set the password of a custom PostgreSQL LOGIN role while ensuring that the plaintext password and authentication verifier material are not exposed through hosted statement logs, error logs, query history, pooler logging, or relevant Supabase control-plane/query-capture systems?
The procedure must not require weakening or disabling security logging.
Please specifically clarify:
1.
Is psql \password considered safe for this purpose under Supabase's hosted logging architecture when log_statement=ddl? Please explain exactly what is and is not captured.
2.
3.
Does Supabase provide a supported dashboard, API, SQL interface, or administrative mechanism specifically for provisioning/resetting credentials for a custom PostgreSQL LOGIN role, rather than only resetting the built-in database password?
4.
5.
Does the protection extend to:
6.
o
successful statements;
o
o
failed statements;
o
o
relevant PostgreSQL query history;
o
o
pooler/control-plane logging or query capture;
o
o
error messages?
o
7.
Can the supported procedure be performed without disabling or weakening security logging?
8.
9.
If custom PostgreSQL LOGIN password provisioning cannot satisfy these requirements, what officially supported authentication/connection alternative do you recommend for a Railway-hosted application that needs:
10.
o
a restricted runtime database identity;
o
o
separation from migration/admin access;
o
o
TLS certificate and hostname validation;
o
o
no production credential sharing?
o
Please provide documentation, applicable configuration requirements and any limitations. We have deliberately paused provisioning pending clarification.  Thank you.

Regards,
Venkat

[R3Dzf]

One distinction worth making here is between the PostgreSQL password-verifier mechanism and the logging behavior of the hosted platform.

PostgreSQL can store a SCRAM-SHA-256 verifier rather than a plaintext password, but that doesn't by itself guarantee that the original credential won't be captured when an administrative statement is submitted.

psql's \password command is preferable to writing a plaintext password directly in an SQL command or migration because it avoids placing the literal password in the generated SQL statement. However, it doesn't establish what Supabase's control plane, query capture, or error logging may retain.

Given your requirement, I'd keep provisioning paused until Supabase confirms the logging boundary and officially supported procedure.

I would also keep the restricted runtime role separate from the migration role, provision credentials outside source control, and use the Railway secret configuration for runtime delivery.

The main unanswered question is whether Supabase can guarantee the absence of both plaintext credentials and authentication verifier material across all the logging surfaces you listed. That's something the provider needs to confirm rather than something we can infer from PostgreSQL behavior alone.

[95436venkat]

Thank you for clarifying the distinction between PostgreSQL password handling and hosted-platform logging.

We understand that psql \password reduces plaintext password exposure but does not, by itself, establish that SCRAM verifier material is excluded from every relevant logging channel.

Could you please provide a project-specific answer for our hosted PostgreSQL 17.11 staging environment?

1. Which supported procedure can we use to provision and rotate a restricted application LOGIN role while preventing both plaintext passwords and SCRAM verifiers from entering retained PostgreSQL statement/error logs, pg_stat_statements, pgAudit records, Supavisor diagnostics and Supabase platform logs, including failed operations?
2. What redaction or exclusion mechanism applies to each channel, and which deployed version provides that protection?
3. If Supabase cannot guarantee exclusion from any of these channels, please identify the uncovered channels and recommend a supported alternative.
4. Separately, can Supabase temporary database access be used by an unattended Railway application? Please clarify the required permissions, token handling and logging protections, expiry/revocation behaviour for existing pooled connections, and supported token renewal strategy.

We intend to preserve security auditing and are not willing to disable necessary logging merely to provision credentials. We will keep provisioning paused until we can establish a supported approach that meets these requirements.