Here's a number worth staring at. In a benchmark Andres Freund ran while working on Postgres connection scalability, one active connection doing simple reads managed 33,457 transactions per second on an otherwise idle server. Add 10,000 connections that do nothing at all, and the same single connection dropped to 14,496 TPS. Nothing else changed. The idle connections weren't running queries. They were just there .

That's the part of connection pooling most teams never think about. They treat pool size as a knob on one service: bump max from 10 to 50 because the API felt slow, ship it, move on. But Postgres doesn't see your services. It sees one flat pile of backend processes, and every service, every replica, every cron job, and every half-finished rolling deploy adds to the same pile.

So let's do this properly.…