Supavisor error: "password authentication failed" after rotating database password

Last edited: 10/14/2026

如果通过 Shared Pooler (Supavisor) (aws-[...].pooler.supabase.com，会话模式下端口 5432 或事务模式下端口 6543) 的连接在你更改数据库密码后不久开始因为 password authentication failed for user "..." 失败，即使新密码是正确的，这是预期的行为，不是BUG——除非这种情况持续发生，否则你不需要当作问题处理。

🌐 If connections through the Shared Pooler (Supavisor) (aws-[...].pooler.supabase.com, port 5432 in session mode or 6543 in transaction mode) start failing with password authentication failed for user "..." shortly after you change your database password, even though the new password is correct, this is expected behavior, not a bug — it isn't something you need to treat as a problem unless it persists.

端口 5432 和 6543 也被直接连接和专用池使用，但在另一个主机 db.[project-id].supabase.co 上。这些不受影响。

🌐 Ports 5432 and 6543 are also used by the direct connection and the Dedicated Pooler, but on a different host, db.[project-id].supabase.co. Those aren't affected by this.

这适用于使用用户名/密码进行认证的常规数据库角色（包括默认的 SCRAM）。它不适用于即时（JIT）访问令牌连接，因为这些连接是在每次连接时实时对 JIT 提供者进行验证，而不是对缓存的密码进行验证。

🌐 This applies to regular database roles authenticating with a username/password (including SCRAM, the default). It does not apply to JIT access-token connections, since those are validated live against the JIT provider on every connection rather than against a cached password.

这是为什么会发生？

连接池器会暂时缓存数据库凭证以提高性能。
在密码刚刚更改后，连接池可能会继续用旧的缓存凭证去检查使用新密码的新连接尝试，从而导致这些连接被拒绝。

如何解决这个问题：

这些步骤涉及 pooler 端的缓存延迟，这个问题会自行解决。

🌐 These steps cover the pooler-side caching delay, which resolves on its own.

另外，如果在修改现有角色的凭证后，应用实例仍使用旧密码连接，那些失败的尝试可能会触发认证断路器，阻止该客户端的连接，并进一步扰乱系统。

🌐 Separately, if application instances keep connecting with the old password after changing an existing role's credential, those failed attempts can trip the auth circuit breaker, blocking connections from that client and disrupting the system further.

为了在不中断的情况下推出密码更改，创建一个带有新密码的自定义角色，同时保留现有密码，逐渐让你的客户端迁移过去，然后在所有客户端都切换完成后再废弃旧角色。

🌐 To roll out a password change without downtime, create a new custom role with the new password alongside the existing one, migrate your clients over to it gradually, then retire the old role once every client has switched.

首先，通过直接连接（绕过连接池），使用像 psql 这样的 Postgres 客户端和新密码确认新密码是否正确。直接连接成功的话，就支持暂时性的连接池缓存诊断。如果直接尝试失败，先检查错误是否是像 28P01 这样的认证失败，然后再判断密码是否错误。
如果直接连接可用，就通过连接池重试。一旦尝试新连接，通常会促使连接池更新新密码。如果你的数据库已经有活跃的连接池连接，这通常也会在大约15秒内自动发生；如果在你更换密码之前连接池处于空闲状态，那么不会自动发生——你需要实际发起一次重连来触发它。
在极少数情况下，速率限制或网络延迟可能导致连续几次重连尝试失败，直到一次成功为止。
避免在短时间内多次更改密码，因为每次更改都会重新开始同一个时间窗口，这会让你更难判断哪次尝试应该成功。
如果直接连接可以正常工作，但几分钟后 pooler 重新连接仍然失败，联系支持并说明直接连接已验证可用，这样可以排除瞬时缓存路径的问题。

另见：