That depends on the provider and the database. For AWS Lambda with DynamoDB connection pooling is handled "behind the scenes", and you don't have to worry about it. AWS supports SQL databases as well, I would assume it also is pooled for you.
NOW currently doesn't have databases and tells you to use cloud DBs. So more than likely the connection is dropped when the lambda shuts down.
But if you'll let me go a little bit meta, the idea of serverless is that you shouldn't even be thinking about things like connection pooling. If you just use the databases that your provide supports those types of concerns are their concerns now, not yours.
In other words, if you want to pick your own tech stack then serverless is not for you (yet). If you're willing to surrender your opinions and just use what the platform provides you (if you're using AWS just use DynamoDB) then you can stop thinking about these problems and focus on your business logic.
Thank you for the detailed answer! That makes sense. Although I still find it strange... Now markets itself as preventing lock-in because it can deploy to any cloud, but to realistically use any database with it you have to lock yourself in to one of the cloud providers?
To expand upon the previous answer. Connection pools are still a problem.
Even if your lambda drops a connection after it destroys itself, a sudden influx of visitors to your site may spawn enough lambda processes to overload your DB.
What happens then is dependent on the database, but generally means that new lambdas do not get to connect.
Anyhow, you don’t really want your database to magically more around regardless, so you’d be sort-of locked in to one service regardless of what you do.
But postgres on one service is pretty much the same as on another, so if you wanted to migrate it would be fairly easy.
What the parent comment is correctly saying is that for certain databases (that are oriented around stateful connections) you might benefit from a infrastructure-level optimization.
However, this is not the case for all databases. Furthermore, modern database vendors are extremely motivated to address the serverless usecase
NOW currently doesn't have databases and tells you to use cloud DBs. So more than likely the connection is dropped when the lambda shuts down.
But if you'll let me go a little bit meta, the idea of serverless is that you shouldn't even be thinking about things like connection pooling. If you just use the databases that your provide supports those types of concerns are their concerns now, not yours.
In other words, if you want to pick your own tech stack then serverless is not for you (yet). If you're willing to surrender your opinions and just use what the platform provides you (if you're using AWS just use DynamoDB) then you can stop thinking about these problems and focus on your business logic.