---
slug: restore-credential-resync
published: 2026-07-30
change_type: bug-fix
affected_products:
  - Database
  - Platform
page: https://supabase.com/changelog/restore-credential-resync
---

# Fixed stale database credentials left behind after a restore

A WAL-G physical restore restores the whole PGDATA directory, including `pg_authid`, so credentials from the backup snapshot overwrote any password rotated after that backup was taken. Credential reapplication was previously only queued when a restore was part of an in-progress clone, so a plain restore to the same project, or an unpause (which shares the same completion path), skipped it entirely and could leave `db_user` with a stale password. Logical restores are unaffected: `pg_dumpall` runs with `--no-role-passwords`, so a logical backup never carries password hashes to begin with.

Supabase now reapplies current credentials after every physical restore completes, regardless of whether it is part of a clone.

A related fix also closes a data-loss path in cloning status tracking: reapplying credentials for a non-clone restore could, on retry exhaustion, flip an unrelated and already-completed clone's status back to failed, which could let a later stray clone request overwrite that project's data. Status transitions are now scoped to clones that are actually in progress.