Fix · Infrastructure
Postgres: "could not translate host name" on a Supabase direct connection.
psql: error: could not translate host name "db.<project>.supabase.co" to address, from a laptop, a container or a cloud runtime that worked elsewhere.
Cause.
Supabase direct database hosts resolve to IPv6 addresses only. A network, a Docker bridge or a cloud runtime without IPv6 cannot resolve or reach them. The connection pooler host resolves over IPv4.
Fix.
| 01 | Switch the host to the pooler: aws-<n>-<region>.pooler.supabase.com, port 5432 for a session connection or 6543 for transaction mode. | |
| 02 | Change the username to the project-scoped form: postgres.<project-ref>. | |
| 03 | Keep the same password; the pooler authenticates against the same roles. | |
| 04 | For migrations and long transactions use the session port; for serverless runtimes use the transaction port. | |
| 05 | Record the pooler connection string in the runbook so the next person does not rediscover this. | |
How the build avoids it.
KYN runbooks carry the pooler string for every Supabase project and the migrations run through it; direct hosts are used only from networks known to have IPv6.
Checked 13 October 2026 against a live build. Vendors change behaviour; if a step no longer matches, tell us and the page changes.
Questions operators ask
Why does it work from my office but not from Docker?
- Docker’s default bridge network has no IPv6. The pooler host resolves over IPv4 from anywhere.
Is the pooler slower?
- Negligibly for application traffic. Session mode behaves like a direct connection; transaction mode cannot hold session state, so prepared statements and advisory locks need session mode.
Does the password change?
- No. The username changes to postgres.<project-ref>; the password is the same database password.
Can I add IPv6 instead?
- Yes on your own servers; on a laptop or a managed runtime it is often not yours to change. The pooler is the dependable route.