Vlad Tkachenko

One thing about the recommended command, for anyone using it as their only backup: --schema=public leaves out auth, so the file has every table and none of the accounts. As a rollback point before a migration that's fine, because you restore into the same project and the users are still there. Not if the project's gone. Restore into a fresh one and nobody can sign in, and if profiles references auth.users (Supabase's own starter does), pg_restore errors on that foreign key too. A second, data-only dump of the auth schema covers it. Data only, because a new project already has its own auth tables and what you want back is the rows in them. Putting those back has two traps Supabase documents, triggers that have to be off during the replay and a couple of owner lines to comment out, which is most of what I wrote up here: https://reeve.page/blog/supabase-backup-auth-users Also, pg_restore -l lists what the dump meant to include, not whether the rows made it in. Restoring into a scratch database and counting a few tables is the check that tells you.

Useful post, and the IPv6 diagnosis is the part most of these guides miss. One thing to check in Step 1 though: the string you landed on uses the pooler's user with the direct connection's host. The shared pooler answers on aws-[INDEX]-[REGION].pooler.supabase.com, not db.[ref].supabase.co. And 6543 is transaction mode, which Supabase's connection guide puts outside pg_dump, under "migrations, pg_dump, backup and restore, or replication... single sessions and Postgres native commands". Session mode, 5432 on that pooler host, is the one it offers "when you connect from an IPv4-only network". Same fix you were reaching for, one port down. Two for the restore post, from a drill we ran on 4 October: roles.sql stops on ALTER ROLE "supabase_admin" and on GRANT SET ON PARAMETER, and pg_cron jobs do not come back, because they are rows in cron.job the data dump skips. Written up at https://reeve.page/blog/how-to-restore-a-supabase-backup