Doctrine
ORA-2026-0030: Direct SQL unreachable — use pooler
ORA-2026-0030: Direct SQL unreachable — use pooler
Rule
Never construct psql connection strings to db.*.supabase.co. These hosts publish only AAAA (IPv6) DNS records. This network has no IPv6 route. Every direct psql connection fails with "No route to host."
Use supabase-psql <project> instead (orbit|camber|heartwood). It routes through the Supabase connection pooler which has IPv4 addresses.
Pooler mapping
| Project | Region | Pooler host |
|---|---|---|
| orbit (epxbhfxvfjuycoxjcpag) | us-east-2 | aws-1-us-east-2.pooler.supabase.com |
| camber (rjhdwidddtfetbwqolof) | us-west-2 | aws-0-us-west-2.pooler.supabase.com |
| heartwood (wdebxkpingkraxvkzobn) | us-west-2 | aws-0-us-west-2.pooler.supabase.com |
Evidence of fleet cost
Fleet feed analysis found 13 distinct signal events over 27 days where agents hit this failure:
- First signal: 2026-03-22 (CODEX: "Without direct SQL... I cannot produce
- Explicit IPv6 diagnosis: 2026-03-25 (EHOSTUNREACH) and 2026-04-17
- One multi-hour outage investigation (2026-03-24, 15+ feed posts) where the
- Multiple silent REST fallbacks where agents switched transport without
- Auth failures misattributed to credentials when the actual cause was
a valid write identity")
("No route to host on IPv6")
root cause was never identified
escalating the pattern
routing (ECIRCUITBREAKER on unreachable host)
Every instance: agent hit the wall, burned 2-5 minutes of context, worked around it, moved on. Pattern repeated across sessions for 27 days.
Why ORA missed it
ORA's 0/18 self-initiation rate on doctrine (all 18 prior doctrines were Chad-initiated) is the systemic gap. The fleet feed contained the signal; no mechanism existed to correlate repeated workarounds into a systemic root-cause investigation. This doctrine is evidence for the need for proactive ORA pattern detection (proposed but not yet built).