Supavisor pool size limits: sizing the pooler versus enforcing client-side connection caps

On a Supabase project fronted by Supavisor, I need to decide how to handle intermittent connection pool exhaustion during bursty traffic. The workload includes serverless functions that each open their own connections through the transaction-mode pool on port 6543, plus a few long-lived services using session mode on port 5432.

The documented trade-off is unclear to me: raising the Supavisor pool size increases the number of server connections held against Postgres max_connections, which can push the database toward memory pressure, while capping client-side pools (Prisma, HikariCP, etc.) shifts queuing into the application. Plan-dependent limits and defaults also appear to have changed over time, so I am unsure which ceiling actually applies.

My specific questions:

• Is there a documented relationship between the Supavisor pool size setting and Postgres max_connections that I should use as a sizing rule of thumb?
• When clients queue because all pooled server connections are checked out, which dashboard metrics or pg_stat_activity states best distinguish true exhaustion from idle-in-transaction hoarding?
• For mixed workloads, is it supported to route bursty serverless clients through transaction mode while keeping session-mode clients on a separate pool, without the two competing for the same backend capacity?