Credential rotation

Credential rotation Changing a database password without dropping traffic. Why it is not just "change the password" A pool holds authenticated connections. Changing the password server-side does not invalidate them — existing connections keep working until they are closed, and the next reconnect fails. So the failure arrives minutes or hours after the change, when a connection is evicted and replaced, and it looks unrelated to what you did. That delay is the whole problem. Plan for two valid credentials at once. The safe order 1. Create a second user with the same grants, rather than changing the existing one's password. 2. Deploy the application pointing at it. Both users are valid, so the rollout can be gradual and a rollback is just the previous deploy. 3. Watch for the old user going quiet. Do not skip this — a forgotten job, a cron, or a replica may still be using it. 4. Drop the old user once nothing has used it for a full cycle of whatever your longest-lived process is. If you must reuse the same username, the same principle applies in a cruder form: change the password, then immediately restart every instance so no pool holds a connection authenticated with the old one. Getting the credential into the process Read it at construction, not at import: prorm reads password once, when it builds the dialect. There is no hook that re-reads it, so rotating a secret in a secrets manager does not reach a running process — it needs a restart, or a new Prorm instance. For short-lived credentials (IAM auth, Vault leases), construct a new instance on the lease boundary and close the old one after its in-flight work drains: If a credential leaked Order matters: revoke first, restore service second. 1. Revoke immediately — ALTER USER … PASSWORD, or drop the user. Accept the outage; a leaked credential in use is worse than downtime. 2. Rotate anything sharing it. If the leak was a repository or an image layer, assume everything in that scope is exposed. 3. Deploy the new credential. 4. Check for damage while access was open: unexpected rows, changed grants, new users. Audit logging is what makes this answerable rather than a guess. Related reading Connection pooling — why pooled connections outlive the change User management — creating roles and grants from code Compliance — audit trails and access controls