Fix

pg_dump says "Network is unreachable" on Supabase

Your connection string is fine. The problem is that Supabase direct connections resolve to IPv6 only, and your machine or CI runner speaks IPv4.

The error

pg_dump: error: connection to server at "db.abcdefghijkl.supabase.co"
(2a05:d012:42e:5700:...), port 5432 failed: Network is unreachable

Why it happens

Since early 2024, the direct host db.<project-ref>.supabase.co resolves to an IPv6 address only. Most home ISPs, many VPS providers, and notably GitHub Actions runners are IPv4-only, so the TCP connection never leaves your machine.

The fix: use the Session Pooler

Supabase's poolers are reachable over IPv4. For pg_dump you need the Session pooler on port 5432, not the Transaction pooler on 6543 (which breaks pg_dump differently). In the dashboard: Connect → Session pooler. The string looks like this:

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

Note the username format: postgres.<project-ref>, not plain postgres. The alternative is Supabase's paid IPv4 add-on on the direct connection, but for backups the Session Pooler costs nothing.

Check before you trust it

A dump that completes is not a backup that works. At minimum, restore it into a throwaway container once:

docker run -d --name drill -e POSTGRES_PASSWORD=drill -p 5499:5432 postgres:17
pg_restore --no-owner -h localhost -p 5499 -U postgres -d postgres backup.dump

Full methodology: how to actually test a Postgres backup.

Or let the drill run itself

pgProof backs up your Supabase project through the Session Pooler on schedule, then restores every backup into a disposable environment and emails you the proof: tables counted, constraints valid, RLS policies present.

Join the early-access waitlist