If your function spends 80% of its time on logic and 20% on database time, with a server app, you can get by with 200 DB connections to handle that throughout, but will need 1000 connections in a serverless setup.
I don't think connection pooling works this way. Happy to be corrected.
A process is given a connection from a pool when it requests the connection and holds it until it relinquishes the connection regardless of whether the process was in the logic or data access portions of their lifecycle. It is up to you as the developer to ask for the connection and to return it on an as-needed basis...Which is exactly what you should be doing in a lambda as well.
Just because a lambda container is persistent does not mean the connection given to it is stuck to that lambda even after that lambda returns the connection.
Lambda does hold onto it in order improve response time. It connects to the database in a handler outside the context of a request, so you do hold onto N connections persistently (at least until the lambda scales down).
With a connection pool, you don’t need to hold onto a connection longer than necessary, but you are right that you could implement it in such a way that you hold it for life of the request.
