Listen does hold a connection, but that doesn't mean it defeats connection pooling. That's what I was trying to convey in this blog post: you'll keep a fixed n

Listen does hold a connection, but that doesn't mean it defeats connection pooling. That's what I was trying to convey in this blog post: you'll keep a fixed number of connections open for use with listen, but as few as possible by reusing a single connection per program to simultaneously listen on all channels that your application cares about (with the notifier distributing messages to each internal component that subscribed). With your dedicated listen connections accounted for, the rest of the connection pool can operate normally, with programs checking connections in and out only as long as they need them. So the net-net is that you have a handful of connections dedicated for listen, and the remaining ~hundreds are part of the connection pool for shared use.