Hosted shared session pooler: upstream TLS identity verification and SSL enforcement

[earnextracashnow26-source]

For Supabase-hosted shared Supavisor in session mode on port 5432, could a maintainer clarify the supported transport guarantees?

1. The SSL enforcement documentation says the setting governs both client-to-pooler and pooler-to-Postgres connections. When enabled, does the upstream leg also validate a trusted certificate chain and the database server hostname/identity? Does it fail closed on verification errors?
2. Supavisor documents separate upstream_ssl, upstream_verify and upstream_tls_ca fields. What guarantees apply to the managed hosted service, and what supported evidence can customers use without accessing managed internals or exposing credentials?
3. Does enabling enforcement require any compatibility changes for managed Auth, Data API, Storage, Realtime or Edge Functions? How are existing pooled connections handled during the documented database restart?

Please link current hosted-service documentation where possible. This is a general architecture/compatibility question; no project-specific diagnostics or secrets are included.

References: SSL enforcement, Supavisor tenant configuration.

[aniket-r2Dev2]

I found a source-level detail relevant to hostname verification, although it does not establish the managed service’s deployed configuration.

The [SSL enforcement documentation](https://supabase.com/docs/guides/platform/ssl-enforcement) says enforcement covers both client-to-pooler and pooler-to-Postgres connections. Encryption and upstream server-identity verification still need to be considered separately.

In [Supavisor’s [ssl_connect](https://github.com/supabase/supavisor/blob/639ea814de61c3e1bf746c20175f0bf4d7bf202f/lib/supavisor/db_handler.ex#L835) implementation at commit [639ea814](https://github.com/supabase/supavisor/blob/639ea814de61c3e1bf746c20175f0bf4d7bf202f/lib/supavisor/db_handler.ex#L835)](https://github.com/supabase/supavisor/blob/639ea814de61c3e1bf746c20175f0bf4d7bf202f/lib/supavisor/db_handler.ex#L835), the upstream_verify = :peer branch configures CA verification and SNI, but also includes:

customize_hostname_check: [{:match_fun, fn _, _ -> true end}]

The :none/nil branch uses :verify_none.

I therefore would not treat upstream_verify = :peer or SNI alone as proof of strict hostname matching. That custom matcher is a specific point for maintainers to clarify, including whether this revision and configuration apply to hosted shared Supavisor.

Likewise, an application connecting to the pooler with sslmode=verify-full verifies the server terminating that connection. It does not configure or attest to the pooler’s separate upstream connection. PostgreSQL explains the client-side verification modes (https://www.postgresql.org/docs/current/libpq-ssl.html)](https://www.postgresql.org/docs/current/libpq-ssl.html).

The remaining hosted-service questions seem to be:

1. Which upstream certificate-chain and hostname checks are guaranteed with enforcement enabled?
2. Does hosted Supavisor use the hostname-matching behaviour above?
3. On upstream verification failure, does reconnection always preserve the same verification requirements?

The documentation also says changing enforcement restarts the database, so interrupted connections should be expected. It does not establish that existing pooled sessions or transactions survive.

This is based on public documentation and source inspection, rather than a hosted-infrastructure test. A maintainer’s confirmation of the deployed behaviour would still be needed to answer your guarantee question fully.

[earnextracashnow26-source]

Does the currently hosted shared session pooler use the upstream hostname-check customization discussed here? If so, what enforces certificate-chain and hostname/identity validation, and does it fail closed? Does incoming SSL enforcement change those checks or only require TLS?