It's a little more nuanced than that. At my company we run Kubernetes workloads where we have 20-30 or sometimes more pods connecting to a single Postgres instance, each pod handling hundreds of concurrent requests. If each pod hangs on to pooled connections for more than a few seconds, then you end up with quite a few Postgres processes and a lot of memory usage and process churn; we mitigate that by having a relatively short TTL on the pool, so idle ones get reaped relatively quickly. But any idle connection not used by a pod can't be used by a different pod. A connection pooler lets all the pods share more connections to Postgres, reducing in less wastage.
replySRE here, that's a ton of pods and sounds like it's language or architecture if you are serving up so few requests per pod.
replyWe have Kubernetes here too for Java monoliths and we have 8 Pods serving more than that. Since Java has connection pooling, the overhead has never been enough to justify overhead of Pgbouncer for this Java app.
Our workloads are served by Go processes, so quite lean. But the workloads are relatively CPU-bound and memory-hungry.
reply> If you have a connection pooler in your application, and the DB is only used for this application, you don't need an external pool like PgBouncer.
replyBut this is only true if you have no more than a few running instances of your application. So it feels like the cases where you must have Postgres (over an alternative like SQLite) but can't justify PgBouncer are very narrow.
Not everything is a SaaS application. There's a lot of software where you only run one or two application servers.
reply