https://sonarly.com/issue/12283?type=bug
The `GetCurrentUser` GraphQL query on `POST /metadata` takes ~2.9s during workspace creation because 6 concurrent `pg.connect` operations each take 1.1-1.4s to establish new TCP connections to PostgreSQL, indicating an exhausted or cold connection pool.
Fix: Added a `PG_POOL_MIN_CONNECTIONS` configuration variable (default: 5) to maintain a minimum number of warm PostgreSQL connections in the pool, preventing the cold-start latency observed in the Sentry trace.
The trace showed 6 concurrent `pg.connect` operations each taking 1.1-1.4 seconds — these were new TCP+SSL connection establishments because the pool had no available connections. By setting a minimum pool size, the `pg.Pool` will proactively maintain at least 5 connections, so burst queries during auth middleware execution (GetCurrentUser resolver) can reuse existing connections instead of waiting for new ones.
**Changes:**
1. **`config-variables.ts`**: Added `PG_POOL_MIN_CONNECTIONS` config variable with default value of 5, following the exact same pattern as `PG_POOL_MAX_CONNECTIONS` (same decorators, metadata group, type).
2. **`global-workspace-datasource.service.ts`**: Added `min` to the `extra` pool options for both primary and replica DataSource configurations, reading from `PG_POOL_MIN_CONNECTIONS`.
3. **`core.datasource.ts`**: Added `min` to the core DataSource's `extra` config, using `process.env.PG_POOL_MIN_CONNECTIONS` (matching the existing pattern of using raw env vars in this static config file).
The `min` option is a standard `pg.Pool` parameter that TypeORM passes through via the `extra` config. This ensures the pool eagerly creates and maintains connections rather than starting from zero.
Sonarly Claude Code
be40eb7484