GitPod Helm chart 0.15.0 raises workspace controller PostgreSQL max connections to 150

In GitPod self-hosted Helm chart 0.15.0, the workspace controller’s PostgreSQL connection pool default increased from 100 to 150, and idle connections are now closed lazily after five minutes of inactivity. The limit remains overridable through GP_POSTGRES_MAX_CONNECTIONS.

The precise goal is to size the pool for peak concurrent workspace start and stop operations without exhausting connections or overloading PostgreSQL. Because the chart exposes no current pool-utilization metric, operators cannot easily predict when concurrent operations will hit the limit. A limit set too high can cause memory pressure on the database, while a limit below peak concurrency reliably produces PG::ConnectionBad errors and workspace provisioning failures.

Does chart 0.15.0 expose workspace-controller pool utilization through any Prometheus endpoint? What formula should determine GP_POSTGRES_MAX_CONNECTIONS relative to peak concurrent workspace operations? How can operators confirm lazy eviction is active without parsing controller logs?