Fix

pg_dump fails through Supabase's Transaction Pooler

Port 6543 is transaction-mode pooling. It juggles your session between server connections, and pg_dump needs one stable session from start to finish.

The symptoms

ERROR: prepared statement "pg_dump_..." does not exist
— or a dump that hangs, or —
pg_dump: error: server closed the connection unexpectedly

Why it happens

In transaction mode, the pooler hands your client a different backend connection for each transaction. Anything that relies on session state breaks: prepared statements, SET parameters, and the consistent snapshot pg_dump holds for the whole run. This is by design; transaction mode exists to serve thousands of short app queries, not maintenance tools.

The fix: same host, port 5432

The Session Pooler keeps one backend per client for the life of the connection, which is exactly what pg_dump, pg_restore, and migration tools need:

Pooler	Port	Use for
Transaction	6543	Your app's queries (serverless, high concurrency)
Session	5432	pg_dump, pg_restore, migrations, psql sessions

pg_dump -Fc -f backup.dump \
  "postgresql://postgres.<PROJECT_REF>:<PASSWORD>@aws-0-<REGION>.pooler.supabase.com:5432/postgres"

If you were on 6543 because the direct connection was unreachable, that is the IPv6 issue — covered here. The Session Pooler solves both at once.

Backups that prove they restore

pgProof handles the pooler details for you, then restore-tests every backup in a disposable container and emails the proof. Failures alert immediately, not the night you need the backup.

Join the early-access waitlist