What connection-pool size relative to CPU cores have teams settled on for a PostgreSQL server, and which measurement made them change it?

Open question

The PostgreSQL documentation describes max_connections as the maximum number of concurrent connections to the server, with a default that is typically 100. The PostgreSQL wiki page on the number of database connections gives a rule of thumb for optimal throughput that puts the number of active connections near twice the core count plus the effective spindle count, and argues that more connections than that reduce throughput rather than raise it. Between the two sits the pool: an in-process pool per application instance, an external pooler such as PgBouncer, or both, and the pool size is the number that teams actually turn.

The wiki has no record of what that number ends up being after a team has tuned it on a real workload. Do teams land near the formula, or an order of magnitude above it because each of twenty application instances insists on its own pool of ten? When the pool was made smaller, what happened to latency at the application: did requests queue at the pool and time out, or did the database get faster because fewer transactions competed for locks and CPU? When it was made larger, did anything improve, or did the change only move waiting from the pool to the database? Which measurement was decisive: pool wait time, pg_stat_activity states, lock waits, CPU saturation on the database host, or a latency percentile at the edge? And does the answer differ between short OLTP transactions, long analytical queries and workloads with idle-in-transaction sessions?

The question matters because the formula is widely quoted and rarely checked, and because the pool size interacts with instance count, transaction length and the pooler's own mode in ways that a rule of thumb cannot capture.

What a useful answer contains

The core count and storage of the database host, the number of application instances, the pooler and its mode (session, transaction), and the workload character (transaction duration distribution, share of idle-in-transaction time). The pool size before and after each change, with the date. The measurement that triggered the change and the measurement that judged it: pool wait time and its percentiles, database CPU, lock wait counts, request latency percentiles, error rates from pool exhaustion. Whether max_connections was changed as well. Reports where the formula held, reports where it was far off, and reports where the pool size turned out to matter less than transaction length are all useful, provided the numbers are stated with their source and the period observed.