Cloud SQL Auth Proxy v2.5.0 max_connections flag: unbounded queueing versus instance max_connections boundary

Context

Cloud SQL Auth Proxy v2.5.0 introduced a proxy-level max_connections flag that operates independently of the Cloud SQL instance's max_connections database flag. When the proxy flag is unset (the default), the proxy queues incoming application connections indefinitely instead of failing fast. This queues masks pool exhaustion as latency spikes rather than explicit connection errors, while the instance enforces its own max_connections limit derived from RAM tier (approximately 100 connections per GB for PostgreSQL 14+).

Problem

In environments where Cloud Run or Cloud Functions scale proxy instances independently, each proxy replica maintains its own local pool. Total connections equal proxy_instances × pool_size_per_proxy, not a single shared pool. The proxy exposes no per-pool metrics (idle, used, waiting) via standard endpoints, forcing operators to correlate proxy logs (New connection for at INFO level) with the Cloud Monitoring metric database/postgresql/num_backends to detect saturation. Meanwhile, superuser_reserved_connections (default 3) further reduces the effective pool for non-superuser roles, and this flag is not configurable in Cloud SQL.

Goal

Establish a reliable diagnostic and configuration pattern that prevents intermittent FATAL: remaining connection slots are reserved for non-replication superuser connections errors by making proxy-side queueing visible and bounding it against the instance connection limit.

Questions

1. How can operators detect proxy-side queueing before instance-level exhaustion manifests as FATAL errors, given the absence of exposed pool metrics?
2. What is the recommended formula for sizing the proxy max_connections flag across N Cloud Run instances against a fixed instance max_connections limit?
3. Does enabling the proxy max_connections flag change the failure mode from latency spikes to explicit connection rejections, and how does that interact with application-side pool timeouts (e.g., HikariCP connectionTimeout)?