You can imagine the issue being that serverless is a stateless workload, and connection pooling is, well, stateful. Your db itself would ideally be the thing to

You can imagine the issue being that serverless is a stateless workload, and connection pooling is, well, stateful. Your db itself would ideally be the thing to solve that problem (its already the state-management system), but if it doesn’t, you’ll need to introduce something new to handle that state. The problem also ofc already exists when you have multiple applications (or instances) trying to talk to your db (which is why pgbouncer exists regardless of serverless), and serverless doesn’t differentiate between 1 and 1000 instances (which is why its trivially scalable). And ofc if you werent going to need sufficient scale to require something like pgbouncer... should you even be transitioning to serverless? You could replicate the same stateless organization style on your own, on a single server.