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.
Or, you could run it on the same server that you're running your database on.
If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it?
Regardless, "serverless" has never meant that there are no servers involved, it just means that for the serverless pieces of your application, you don't have to concern yourself with where or how they're run, only with the application logic itself.
If you want to go 100% serverless, then you're obviously going to have to choose a DBaaS that works with your connection pooling strategy, especially if that strategy is "I don't have one." Supposedly, based on comments on this thread, DynamoDB works pretty well for that scenario. Obviously Postgres doesn't scale with an increasing number of connections very well, which is why PgBouncer exists, and it works well.
Finally, PgBouncer is relatively stateless. Its main pieces of state are a static config file and the pool of open connections it holds. This could be deployed in a serverless fashion, and any time it is destroyed or recreated, it would be trivially reinitialized just from the config. It doesn't have to have any attached, mutable storage.
> If you're not running the database server yourself, is it so unimaginable that the service provider might have already configured PgBouncer on top of the database as an optional way to interface with it?
Are you familiar with any providers that offer this configuration? In my experience, at least AWS does not.
This is something that is only necessary for legacy databases. Modern database providers give you gateways that deal with a huge number of connections with no issues.
