Pooler accepts TCP but Postgres handshake fails — project qykgmpwyztxvyyfzdgds (eu-central-1)

[marvinmanex-cyber]

TL;DR: External connections to my pooler endpoint (aws-1-eu-central-1.pooler.supabase.com:5432) fail with P1001 via Prisma, even though TCP connects fine, the DB itself is ACTIVE_HEALTHY, and Supabase's own Management API can query it successfully. Started 2026-06-30, still ongoing as of today (2026-07-07).
Project ref: qykgmpwyztxvyyfzdgds (region: eu-central-1, free plan)
What's failing
Every external client (Prisma CLI, tested from multiple environments) fails to connect with:
Error: P1001
Can't reach database server at aws-1-eu-central-1.pooler.supabase.com:5432
This has completely blocked schema migrations (prisma db push/migrate) for over a week now.
What I've confirmed works
• Project status: ACTIVE_HEALTHY, Postgres 17.6.1.141
• Running SQL via the Management API succeeds right now (select now() → returned a real, current timestamp)
• Postgres logs show Supavisor successfully authenticating internally:
• connection authorized: user=pgbouncer database=postgres application_name=Supavisor (auth_query)
• Raw TCP connects fine to aws-1-eu-central-1.pooler.supabase.com:5432 — DNS resolves correctly to your eu-central-1 load balancer, socket opens successfully
Where it actually breaks
Immediately after the TCP handshake succeeds, the Postgres/TLS protocol handshake never completes — the client just times out. So this looks like an L7 (application-layer) issue behind an otherwise-healthy L4 (TCP) load balancer, not a DNS/network/firewall problem, and not the database engine itself (which I can reach and query fine through the Management API).
Impact
My production app (deployed separately via Vercel, connects through a different path) is still serving traffic, but any feature depending on schema changes made in the last week is broken — confirmed directly in my own Postgres logs, which show recurring relation does not exist / column does not exist errors from real application queries.
Already tried
• Upgraded Postgres to 17.6.1.141 (per the "Project status change failures in multiple regions" incident guidance)
• Restarted the project twice, most recently 2026-07-07 ~11:50 UTC — restart completed cleanly per the logs, but external pooler connectivity still fails afterward
Is anyone else on eu-central-1 seeing the same TCP-connects-but-handshake-hangs pattern? Any pointers from the Supabase team on the Supavisor instances behind this pooler endpoint would be much appreciated — happy to share more logs/timestamps if useful.

[harrysun2006]

The fact that raw TCP opens but the Postgres/TLS handshake never completes, while the Management API can still query the DB, is the useful clue here — the Management API talks to your database over a completely different internal path, so it staying green doesn't tell you much about the pooler's external listener. What you're describing is the pooler (Supavisor) accepting the socket and then stalling before the startup packet completes.

A few things to check/try before assuming it's an incident:

• Username format. On the pooler you must connect as postgres.qykgmpwyztxvyyfzdgds (role + project ref as the tenant), not bare postgres. A wrong tenant can get you a socket that then hangs on the startup exchange.
• Prisma + pooler mode. Port 5432 on ...pooler.supabase.com is session mode, 6543 is transaction mode. prisma migrate/db push need session mode or (better) a direct connection, because migrations use advisory locks and prepared statements that transaction pooling doesn't support. Point Prisma's directUrl at the direct connection (db.<ref>.supabase.co:5432, or enable the IPv4 add-on if you're IPv4-only) and keep the pooler for the app's url with ?pgbouncer=true.
• SSL. Make sure the connection string has sslmode=require — a missing TLS param behind the load balancer can look exactly like "connects then hangs".

If you've already got the username/port/sslmode right and a direct connection also stalls while internal Supavisor auth keeps succeeding, then it really is pooler/LB-side for your project and there's nothing you can fix from the client — open a support ticket with the project ref (this overlaps with the pooler issues some eu-central projects saw starting late June). If you can share your exact connection string shape (host, port, username pattern, sslmode) I can sanity-check it.

[marvinmanex-cyber]

Thanks for the detailed pointers — checked all three:

Username: already correct, postgres.qykgmpwyztxvyyfzdgds (not bare postgres)
SSL mode: tested adding sslmode=require to the connection string directly — no change, still P1001, connects then hangs the same way
Port/mode: DIRECT_URL is on port 5432 on the pooler host (session mode), which you noted should work for migrations. I also tried resolving the true direct host, db.qykgmpwyztxvyyfzdgds.supabase.co — it doesn't resolve at all from my environment (No address associated with hostname), so that's likely the IPv6-without-add-on situation you mentioned. I don't have a way to test a true direct connection without enabling that add-on.
Connection string shape, as requested (password redacted):

postgresql://postgres.qykgmpwyztxvyyfzdgds:REDACTED@aws-1-eu-central-1.pooler.supabase.com:5432/postgres

So per your own breakdown — correct username, correct SSL, session mode on the pooler, and it still stalls after TCP connects while Supavisor's own internal Postgres auth keeps succeeding in the logs — this does look like it's pooler/LB-side for this project rather than a client misconfiguration. I've also opened a support ticket (project ref qykgmpwyztxvyyfzdgds) referencing this thread. Appreciate you working through this with me either way.

I would really appreciate if you could help me resolve this. It's affecting me very much.

[harrysun2006]

You've isolated it correctly: correct tenant username, sslmode=require, session mode on 5432, and it still stalls after TCP while Supavisor's internal Postgres auth keeps succeeding in the logs — that combination really does point at the pooler/LB listener for your project, not your client. And the db.<ref>.supabase.co "no address" is expected, not a second bug: direct connections are IPv6-only now unless you add the IPv4 add-on, so on free tier the pooler is your intended path — which is exactly why it being broken is worth escalating rather than working around. I should be upfront: I'm another community member, not Supabase staff, so I can't touch your project's infra — the support ticket is genuinely the only route to the actual fix here.

That said, two things will make the ticket move faster, and one will get you unblocked today.

Sharpen the ticket (2 min each):

1. Prove it's the transport, not Prisma — try plain psql on the same string:

   psql "postgresql://postgres.qykgmpwyztxvyyfzdgds:REDACTED@aws-1-eu-central-1.pooler.supabase.com:5432/postgres?sslmode=require"
   

   If psql hangs identically, that rules out Prisma entirely — attach it to the ticket.
2. Test the transaction pooler on 6543 (same host, port 6543). If 6543 connects but 5432 hangs, that pins it to the session-mode listener specifically — a very useful signal for support, and it means your app's normal (non-migration) traffic could run via 6543 in the meantime.

Unblock migrations now, without the pooler: since the Management API / SQL editor works, generate the migration SQL locally and apply it there. No database connection needed:

npx prisma migrate diff \
  --from-migrations ./prisma/migrations \
  --to-schema-datamodel ./prisma/schema.prisma \
  --script > pending.sql

(Use --from-empty instead of --from-migrations ... if the DB has never had migrations applied.) Paste pending.sql into the Supabase SQL Editor and run it. Then, if you're on the migrate workflow, tell Prisma it's applied so state stays in sync:

npx prisma migrate resolve --applied <the_migration_name>

If you're using db push rather than migrate, just running the diffed SQL in the editor is enough. That gets your week of blocked schema changes in today, independent of whatever's wrong with the pooler.

I know a week of being blocked is rough — the SQL-editor route should get you moving right now, and the psql/6543 results are the fastest way to get support to the actual root cause. Share those two results here and I'll help you read them.

[marvinmanex-cyber]

Thanks for the detailed pointers — checked all three: - *Username*: already correct, postgres.qykgmpwyztxvyyfzdgds (not bare postgres) - *SSL mode*: tested adding sslmode=require to the connection string directly — no change, still P1001, connects then hangs the same way - *Port/mode*: DIRECT_URL is on port 5432 on the pooler host (session mode), which you noted should work for migrations. I also tried resolving the true direct host, db.qykgmpwyztxvyyfzdgds.supabase.co — it doesn't resolve at all from my environment (No address associated with hostname), so that's likely the IPv6-without-add-on situation you mentioned. I don't have a way to test a true direct connection without enabling that add-on. Connection string shape, as requested (password redacted): postgresql:// ***@***.***:5432/postgres So per your own breakdown — correct username, correct SSL, session mode on the pooler, and it still stalls after TCP connects while Supavisor's own internal Postgres auth keeps succeeding in the logs — this does look like it's pooler/LB-side for this project rather than a client misconfiguration. I've also opened a support ticket (project ref qykgmpwyztxvyyfzdgds) referencing this thread. Appreciate you working through this with me either way. I would really be grateful if you could help me resolve this. It affects me very much. Thank you!

…

On Tue, Jul 7, 2026 at 10:57 PM Harry Sun ***@***.***> wrote: The fact that raw TCP opens but the Postgres/TLS handshake never completes, while the Management API can still query the DB, is the useful clue here — the Management API talks to your database over a completely different internal path, so it staying green doesn't tell you much about the pooler's external listener. What you're describing is the pooler (Supavisor) accepting the socket and then stalling before the startup packet completes. A few things to check/try before assuming it's an incident: - *Username format.* On the pooler you must connect as postgres.qykgmpwyztxvyyfzdgds (role + project ref as the tenant), not bare postgres. A wrong tenant can get you a socket that then hangs on the startup exchange. - *Prisma + pooler mode.* Port 5432 on ...pooler.supabase.com is session mode, 6543 is transaction mode. prisma migrate/db push need session mode or (better) a *direct* connection, because migrations use advisory locks and prepared statements that transaction pooling doesn't support. Point Prisma's directUrl at the direct connection (db.<ref>. supabase.co:5432, or enable the IPv4 add-on if you're IPv4-only) and keep the pooler for the app's url with ?pgbouncer=true. - *SSL.* Make sure the connection string has sslmode=require — a missing TLS param behind the load balancer can look exactly like "connects then hangs". If you've already got the username/port/sslmode right and a *direct* connection also stalls while internal Supavisor auth keeps succeeding, then it really is pooler/LB-side for your project and there's nothing you can fix from the client — open a support ticket with the project ref (this overlaps with the pooler issues some eu-central projects saw starting late June). If you can share your exact connection string shape (host, port, username pattern, sslmode) I can sanity-check it. — Reply to this email directly, view it on GitHub <#47703?email_source=notifications&email_token=B76HLKJ5EE425OBKB3D7Z735DVW6FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVGY2TCMRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17565123>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B76HLKON5BIQLR3O6ZTEZND5DVW6FAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMBTHA3TGMJQUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/B76HLKIJ6FGF3STKMWMGVV35DVW6FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVGY2TCMRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/B76HLKIAKMNPZQBBKRHPAA35DVW6FA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVGY2TCMRTUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[GaryAustin1]

First you are talking to someone using an AI to do this answer/help. Might work out, might not.

Does your password contain special characters? If so that can mess up the Prisma URL string as it gets corrupted.

Try use PSQL with the same string from your computer to sort if it is the string/supavisor/instance versus Prisma setup.

Also note you are not likely to be seen here by anyone from Supabase. There are no mass issues though with Supavisor being reported here or Discord, so likely something specific to your instance or your configuration and passing of the URL.

[yakubka]

The pattern you are describing (TCP connects, L7 handshake never completes, Management API works) is consistent with the Supavisor process behind the pooler endpoint being in a degraded state while the underlying Postgres engine is fine. The Management API goes through a different path than the pooler, which is why one works and the other does not.

A few things to try before escalating to support.

First, try port 5433 instead of 5432. Port 5432 is transaction mode, 5433 is session mode. They hit different Supavisor configurations and occasionally one is degraded while the other is not.

Second, try making the SSL mode explicit in your connection string. Supavisor sometimes behaves differently when the client does not negotiate SSL upfront. Add ?sslmode=require to your DATABASE_URL and retry.

Third, try the direct database connection string (not the pooler) to confirm whether Prisma migrations can go through the direct connection. The direct connection bypasses Supavisor entirely and connects to Postgres on port 5432 at the db.your-ref.supabase.co host. For migrations this is actually the recommended approach since Prisma db push and migrate use DDL statements that do not work well with transaction-mode pooling.

If none of these help, open a support ticket at supabase.com/support with your project ref, the exact timestamps of the failed connection attempts, and a note that the project was restarted on 2026-07-07 without resolving it. The team will need to look at the Supavisor instance directly.