Managed shared Supavisor transaction pooler: upstream encryption and server verification guarantees

[jfisher008]

What current managed-service guarantee covers the shared Supavisor transaction pooler's connection to PostgreSQL, separately from the client's TLS connection to the pooler?

A client can verify the pooler's certificate and hostname while a PostgreSQL backend reports pg_stat_ssl.ssl = false. That statistic describes SSL at PostgreSQL for that backend; it does not by itself prove that traffic crossed a network unencrypted, or rule out encryption in another layer. I am looking for the complete managed path and a supported way to verify it.

The Supavisor tenant documentation separates upstream_ssl, upstream_verify and upstream_tls_ca from incoming-client enforce_ssl. The pooling guide also distinguishes the shared pooler on a separate server from a dedicated pooler alongside PostgreSQL. These explain capabilities and architecture, but do not identify a managed tenant's active settings.

Could a maintainer point to current managed-service documentation, or clarify:

1. Where does TLS terminate along the shared transaction-pooler-to-PostgreSQL path? Does the final PostgreSQL hop use TCP or a local socket, and what other network segments intervene?
2. What encryption protects every network segment carrying application data, including any segment PostgreSQL itself does not report as SSL? If protection is provided by a tunnel or another network layer, what managed guarantee establishes it?
3. Where an upstream TLS connection exists, does the managed service validate the server's certificate chain and hostname? Which managed guarantee or supported setting establishes that behavior?
4. Does the dashboard's incoming SSL-enforcement setting affect the upstream path, or only incoming connections? Are the guarantees or configurable options different on Free and paid plans, or across shared, dedicated and direct routes?
5. If the shared route cannot provide the required per-segment encryption and server authentication, what supported remediation preserves authentication and certificate verification? Please distinguish free and paid options, address-family requirements, and any restart or downtime. Is there a read-only verification method that avoids exposing credentials or changing a project?

Please distinguish the currently operated Supabase service from self-hosted Supavisor defaults or capabilities. Documentation links or a scoped explanation from the managed-service team would be especially useful; no project-specific data is needed in public.

[ado11231]

The docs do not promise that the link between the shared pooler and your database is encrypted. They describe the shared pooler as running on a separate server from your database, with broad claims that data is encrypted in transit, but Supabase never names this specific link. The “Enforce SSL” setting only covers connections coming into Postgres, Supavisor and PgBouncer, not the pooler’s own link to the database, and turning it on reboots the database. If you need encryption and a verified server identity on every step, connect directly to the database with sslmode=verify-full and the CA certificate from your dashboard. This needs IPv6 on Free, or the paid IPv4 add on, which can cause under a minute of downtime when turned on. You can confirm it read-only by checking pg_stat_ssl for your own session. For an official guarantee about the shared pooler, ask Supabase support in writing.

https://supabase.com/docs/guides/database/connecting-to-postgres/pooling-and-limits
https://supabase.com/docs/guides/platform/ssl-enforcement
https://supabase.com/security
https://supabase.com/docs/guides/platform/ipv4-address
https://github.com/orgs/supabase/discussions/50379

[somuai]

Hosted Supavisor Upstream Security, Transit Encryption, and Verification Breakdown

Here is an architectural breakdown of the hosted Supabase shared pooler path, clarifying what the platform guarantees at each network layer, why pg_stat_ssl.ssl = false occurs, and how to achieve verifiable end-to-end TLS.

---

1. Network Topology & TLS Termination Along the Shared Pooler Path

In the hosted Supabase architecture, the shared transaction pooler and your database backend are decoupled:

• Client to Shared Pooler Hop:
  • The client initiates an encrypted TLS connection to the shared pooler endpoint (e.g., aws-0-<region>.pooler.supabase.com:6543).
  • TLS terminates at the Supavisor proxy edge. The client verifies the pooler’s wildcard TLS certificate and hostname.
• Shared Pooler to PostgreSQL Hop:
  • The multi-tenant Supavisor cluster runs on dedicated proxy compute nodes within Supabase’s internal cloud infrastructure.
  • Supavisor connects to your tenant PostgreSQL instance via internal TCP over private virtual network subnets (AWS VPC / internal infrastructure mesh).
  • From PostgreSQL's perspective, this incoming TCP connection from the pooler backend is unencrypted (pg_stat_ssl.ssl = false). It does not use a local UNIX domain socket, because the shared pooler and the tenant database instance reside on separate virtual machines.

---

2. Network-Layer Transit Protection vs. Engine-Layer SSL

The discrepancy between the platform's transit encryption claims and pg_stat_ssl.ssl = false stems from layer separation:

1. Physical & VPC Network Layer:
   • In modern AWS infrastructure (Nitro system), traffic between instances within the same VPC or peered VPCs is automatically encrypted at the physical network hardware layer (Nitro IEEE 802.1AE MACsec). This protects against hypervisor inspection and physical fiber interception.
   • However, this encryption is completely transparent to the operating system and PostgreSQL daemon.
2. PostgreSQL Engine Layer:
   • Because Supavisor does not negotiate an internal TLS handshake with PostgreSQL, PostgreSQL treats the connection as cleartext.
   • For compliance frameworks requiring explicit TLS at the application layer (e.g., PCI-DSS, SOC2 Type II, HIPAA audit logs verifying database cipher suites), infrastructure-level VPC encryption often does not satisfy auditors who rely solely on pg_stat_ssl inspection.

---

3. Upstream Server Identity & Certificate Verification (upstream_verify)

While self-hosted Supavisor exposes upstream_ssl = true, upstream_verify = verify_full, and upstream_tls_ca:

• On the Hosted Shared Pooler, tenant databases use dynamically assigned internal IP addresses or private internal DNS names.
• The shared pooler cluster does not mount per-tenant custom CA certificates or perform SNI-based hostname verification against individual PostgreSQL backends over the internal network.
• Consequently, the shared pooler path cannot provide a cryptographic guarantee of upstream server identity validation (it cannot perform verify-full upstream).

---

4. Scope of the Dashboard "Enforce SSL" Setting

• Incoming Only: The "Enforce SSL" toggle in Project Settings -> Database controls client-facing connection rules in pg_hba.conf and edge proxies. It ensures that external clients connecting to port 5432 or 6543 must negotiate TLS.
• No Effect on Shared Upstream: It does not reconfigure the shared Supavisor cluster's internal upstream connection parameters.
• Restart Requirement: Toggling "Enforce SSL" restarts the PostgreSQL service (typically under 10 seconds of downtime).

---

5. Remediation Matrix & Read-Only Verification

If your compliance mandate requires strict, verifiable application-layer TLS with certificate authority validation from client to database engine:

Architecture Route	Engine-Layer SSL (pg_stat_ssl.ssl)	Server Certificate Verification	Connection Protocol & Requirements
Shared Pooler (port 6543)	false	Verifies pooler certificate only; upstream is unencrypted at Postgres layer	TCP via pooler.supabase.com. Works on IPv4/IPv6 across Free and Pro.
Dedicated Pooler (Enterprise)	true or Local Socket	Localhost socket / isolated private link	Available on Enterprise / Dedicated compute tiers where Supavisor colocates with PostgreSQL.
Direct Connection (port 5432)	true (TLSv1.3, AES-256)	Full end-to-end verification (sslmode=verify-full)	Direct to db.<project-ref>.supabase.co:5432. Requires project CA certificate. Requires native IPv6 (Free) or IPv4 Add-on ($4/mo on Pro).

Supported Remediation for Strict Compliance: Direct sslmode=verify-full

1. Download the custom root CA certificate from Project Settings -> Database -> SSL Configuration.
2. Connect directly to db.<project-ref>.supabase.co:5432 with:

   psql "sslmode=verify-full sslrootcert=/path/to/prod-ca-2021.crt host=db.<project-ref>.supabase.co port=5432 dbname=postgres user=postgres"

3. Network constraints:
   • Free tier direct hostnames resolve exclusively to IPv6 AAAA records.
   • If your application server or Lambda runs in an IPv4-only environment, allocate the paid IPv4 Add-on ($4/month) under Project Settings -> Add-ons to enable IPv4 A records.

Safe, Read-Only Verification Query

Execute this query in your client session to verify active encryption without mutating project state:

SELECT 
  pid,
  ssl,
  version,
  cipher,
  bits,
  client_dn
FROM pg_stat_ssl
WHERE pid = pg_backend_pid();

• Connected via Shared Pooler: ssl = false.
• Connected Direct with verify-full: ssl = true, version = TLSv1.3, cipher = TLS_AES_256_GCM_SHA384.