Separate Postgres credential rotation from user sign out

Rotating the password in a Postgres connection string changes how the backend connects to its database. It does not revoke the application's user sessions. With Own Auth, those sessions remain records checked by the authentication package. PgBouncer sits between the database client and Postgres; it does not replace that application session check.

The distinction matters during an incident. An exposed database credential and a stolen browser session need different containment. Changing one password may restore control of a database connection while leaving a stolen application token usable. Revoking application sessions may stop browser access while a compromised database role can still read its permitted tables. Identify which credential escaped before choosing the action.

Identify the client at each connection

A typical request passes through a browser, a backend, a connection pool, and Postgres. The browser presents the application's session credential to the backend. The database driver presents database credentials when it connects to PgBouncer. PgBouncer then connects to Postgres according to its configured database and authentication settings.

These identities can be related operationally without being the same principal. Thousands of application users may share one backend database role. The database connection tells Postgres which role's grants apply. It does not tell the application which person owns the browser request or which organisation that person is allowed to manage.

Keep PgBouncer authentication at the database layer

PgBouncer's authentication configuration controls database clients. Depending on the deployment, it can use an authentication file or a configured query to obtain database login information. These options should be reviewed alongside the upstream Postgres role and the pooler's own authentication user. They do not describe password login, magic links, or session expiry for the application's customers.

An application user changing their password does not normally require a PgBouncer reload. The authentication package updates the application credential records through its supported methods. Conversely, rotating the backend's database password is an infrastructure operation. It needs coordination across the applications, workers, migration runners, and poolers that actually use that database role.

Verify a fresh connection after rotation

A running service may continue answering requests through connections that were already established. That is useful for availability, but it can hide an incomplete credential change. A successful request through a warm pool does not establish that a newly started worker or replacement application instance can connect with the intended credential.

Validate the new connection path explicitly, including the pooler and upstream database. Inventory every consumer before retiring the old credential. A deployment that updates the web process but misses a scheduled worker may appear successful until that worker next opens its connection. The important evidence is a new authenticated connection from each intended consumer, not only continued traffic on an existing one.

Revoke application sessions through Own Auth

Own Auth verifies an opaque session token against stored session state through auth.getCurrentSession. A revoked, expired, or disabled user's session fails that lookup. Session revocation belongs to the package's session operations, such as auth.revokeSession for one session and auth.revokeAllSessions for a user's sessions. Database role password rotation does not perform those operations.

Choose the revocation scope from the evidence. A stolen device session may require removing one session. An account compromise may require broader recovery and revocation. A leaked database credential can expose a wider set of records and demands its own investigation. Do not describe a connection password change as proof that affected application accounts have been secured.

Keep token protection separate from database access

The token pepper is another credential with a different purpose. Own Auth uses OWN_AUTH_TOKEN_PEPPER when protecting token verifiers. Changing that value is not a transparent replacement for rotating a Postgres password. It can invalidate credentials protected with the earlier value, so it changes application access rather than merely selecting a new database login.

Keep the pepper stable across the intended application instances and store it as a server secret. A replacement worker that receives a different pepper can fail to validate otherwise correct credentials even when its database connection succeeds. A healthy connection pool therefore proves database reachability, not the complete correctness of the authentication configuration.

Preserve the distinction in incident evidence

Record which database role was rotated, which consumers opened fresh connections, and which application sessions were revoked. Those are separate results. Keep raw passwords, connection strings, browser cookies, and session tokens out of the record. Safe resource names and operation outcomes should explain the containment without creating another copy of the escaped credential.

The Postgres authentication guide covers the package connection and migrations. The session documentation covers application session validity and revocation. Use each system's established owner for its credential, then verify both the database connection and the protected application request that depend on it.