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 th

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.