[rmrfrmrf]

Traditionally, a web application creates a group of always-on reusable connections (a pool) to a database server since setting up the connection takes time and each connection uses up resources on the database server that could otherwise be used for computation. If there are more connections to your API that require the database than there are connections in the pool, those requests are queued and handled when the next connection is freed. These connections are then closed when the app shuts down.

The problem on Lambda is that you can’t persist any application state beyond the function call itself, so you can’t take advantage of connection pooling the way you normally would in a self-contained webapp. Without some kind of middleman, each database call will require you to open a new connection to the database and close it when the function ends. This becomes catastrophic for the database server as the number of requests scales up.

[mrep]

Yes you can. You are supposed to instantiate those connections outside the function call as per the docs.

Example: https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds-deploym...

[alexnewman]

Tried and failed

[jdchernofsky]

http://blog.spotinst.com/2017/11/19/best-practices-serverles...