Edge Function → dedicated PgBouncer (:6543): rare CONNECT_TIMEOUT that looks like an Edge Runtime worker stall, not a slow handshake

[AlexandraBeseda]

Setup

• Pro plan, us-east-1, Edge Runtime 1.76.0 (Deno 2.1.4), postgres-js 3.4.9, connect_timeout = 10 s.
• pg_cron (every minute) → pg_net → Edge Function, which opens a connection to the dedicated
  PgBouncer db.<ref>.supabase.co:6543 (IPv6-only host, no IPv4 add-on).
• Every invocation is a cold boot (boot p50 166 ms, max ~1 s).

Symptom
About 1 in 9,000 invocations fails with write CONNECT_TIMEOUT db.<ref>.supabase.co:6543.
20 events in ~90 days across two projects (production and staging). Latest: 2026-09-25 14:23:29 UTC.

Why we think the worker stalls, not the network

• Normal runs log in to PgBouncer at seconds :00–:05 of the minute, ~30 ms per login.
• The failures fire at seconds :11–:31. A slow handshake with a 10 s timeout would fail at :10–:15.
  Most failures are later than that, so the invocation started late or its timer fired late.
• In one case the function's timer fired at 15:45:25, the socket reached the pooler around :26,
  and PgBouncer logged client_login_timeout (age=60s) at 15:46:26.

Questions

1. Is a late start or a pause of an Edge Runtime worker (cold boot, event-loop freeze) a known
   behaviour on 1.76.0?
2. For an Edge Function running every minute, which endpoint do you recommend: dedicated PgBouncer
   over IPv6, the shared Supavisor pooler over IPv4, or the IPv4 add-on?
3. Is a 10 s connect_timeout reasonable here, or should we go back to the library default of 30 s?

Support ticket SU-473490 (opened 2026-09-14) has project refs, timestamps and request IDs,
but there has been no reply beyond the auto-acknowledgement.

[somuai]

Diagnostic Analysis & Answers to Your 3 Questions

The combination of the Edge Function timestamp (:11–:31), the client-side write CONNECT_TIMEOUT, and PgBouncer logging client_login_timeout (age=60s) at 15:46:26 provides the exact signature of what happened.

---

Root Cause: Socket Handshake Asynchrony and Isolate Freezing

The key diagnostic signal is:

"socket reached the pooler around :26, and PgBouncer logged client_login_timeout (age=60s) at 15:46:26"

This proves that:

1. The TCP SYN/ACK handshake actually succeeded and PgBouncer accepted the incoming socket at 15:45:26.
2. However, PgBouncer never received the PostgreSQL SSLRequest / Startup message packet within its 60-second window, so it terminated the connection (client_login_timeout).
3. On the Edge Function side, postgres-js started its internal connect_timeout = 10 timer when the connection promise was instantiated. Because the Edge isolate experienced cold-boot scheduling latency or event-loop starvation during V8 snapshot initialization and IPv6 route negotiation, the 10-second timer tripped client-side at second ~:36.
4. When postgres-js aborted, the underlying socket was either abandoned or half-closed while the worker completed or terminated, leaving an unauthenticated TCP connection sitting in PgBouncer's epoll backlog until PgBouncer's 60s reaper killed it.

---

Direct Answers to Your Questions

1. Is a late start or pause of an Edge Runtime worker a known behavior on 1.76.0?

Yes. In Deno 2.1.4 / Edge Runtime 1.76.0, cold boots on worker isolates can experience p99/p99.9 latency spikes under two specific circumstances:

• Isolate Provisioning & Snapshot Deserialization: When traffic is bursty (e.g. firing right at the top of the minute via pg_cron), the host runner spins up a fresh isolate. If the underlying host is handling concurrent cold starts, V8 isolate initialization can slip from ~160 ms to several seconds.
• IPv6 Dual-Stack Route Discovery: db.<ref>.supabase.co:6543 resolves strictly to AAAA records when the IPv4 add-on is omitted. In AWS us-east-1, edge-to-VPC IPv6 egress routes occasionally experience transient route cache revalidation delays during cold socket establishment. Because postgres-js computes connect_timeout inclusive of DNS resolution and socket negotiation, any delay in TCP initialization eats directly into your 10s budget.

2. Which endpoint is recommended for a 1-minute scheduled Edge Function?

The Supavisor connection pooler over dual-stack IPv4/IPv6 (aws-0-<region>.pooler.supabase.com:6543 / 5432).

• PgBouncer Deprecation: Dedicated PgBouncer instances on Supabase are legacy and deprecated in favor of Supavisor, which provides active multi-tenant connection pooling, substantially faster connection setup times, and full dual-stack IPv4/IPv6 availability.
• Eliminating the Hairpin Hop:
  Consider your architecture: PostgreSQL (pg_cron) → pg_net → Edge Function → PgBouncer (:6543) → PostgreSQL.
  • If the Edge Function only executes database queries (without calling external 3rd-party REST APIs or running heavy external compute), you can eliminate the network hop entirely by running a stored procedure directly in PostgreSQL scheduled via pg_cron:

    select cron.schedule('my-minute-job', '* * * * *', 'call my_schema.my_stored_procedure()');

    This eliminates cold starts, network latency, TLS handshakes, and connection pool exhaustion with 0% failure rate.
  • If you must use an Edge Function (e.g., to fetch third-party webhooks or perform external transformations), connect to Supavisor using transaction mode (pool_mode=transaction on port 6543) or session mode (5432) and always ensure await sql.end() is invoked in a finally block to prevent lingering socket retention.

3. Is a 10 s connect_timeout reasonable, or should you revert to 30 s?

Revert to at least 20 s – 30 s.

In serverless and edge compute environments:

• 10 seconds is too aggressive for an environment where isolate boot, V8 microtask scheduling, DNS resolution, and TLS handshake over IPv6 must all complete before the first query executes.
• Setting connect_timeout = 30 (or 20) will eliminate false-positive client-side timeouts during edge-isolate scheduling spikes without holding up healthy connections (healthy connections still complete in ~30 ms).

Additionally, configure postgres-js with explicit connection termination:

import postgres from "https://deno.land/x/postgresjs@v3.4.9/mod.js";

Deno.serve(async (req) => {
  const sql = postgres(Deno.env.get("SUPABASE_DB_URL")!, {
    connect_timeout: 30,
    idle_timeout: 5,
    max: 1, // Single connection per isolate execution
    prepare: false // Required for PgBouncer / Supavisor transaction mode
  });

  try {
    const result = await sql`SELECT 1`;
    return new Response(JSON.stringify(result), { headers: { "Content-Type": "application/json" } });
  } finally {
    await sql.end({ timeout: 5 });
  }
});

[AlexandraBeseda]

Thanks for taking the time. Two corrections for anyone reading later, and the question is still open for Supabase staff.

• The dedicated pooler (PgBouncer) is not deprecated. The current docs list it as the paid-plan option, co-located with Postgres, with lower latency than the shared pooler: https://supabase.com/docs/guides/database/connecting-to-postgres
• The shared pooler (Supavisor) is IPv4-only per the same page, not dual-stack.

On the timeline: in our case the client timer fired at 15:45:25 and the socket reached the pooler about a second later, not the other way round. That ordering is why we suspect the worker paused rather than the handshake being slow.

The failure is harmless for us (the next cron minute retries), so we are not raising the timeout. We have added timing fields to the error report and will post them here with the next occurrence.

Still hoping for a staff answer on question 1: is a late start or pause of an Edge Runtime worker a known behaviour on 1.76.0?