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.

I am not sure to what the op was referring, but I’d make sure to plex your connections through a configured connection pool to ensure the highly liquid lambda compute doesn’t suffocate the database.

What happens if you get 1M requests. How many dB connections is this?