[mjb]

That's right. Make connections to databases (and most other things) the first time your Lambda handler runs, and stash them in a static/global variable for re-use on future runs. That allows you to amortize the cost of forming the connection over many executions of your function, which improves latency, reduces cost, and reduces load on the backend.

[k__]

Well, amortize sounds a bit funny when the first user basically has to pay the whole cold run, hehe

[sologoub]

Haven't heard of this approach yet. Do you have a write up I could reference to try it out?

[k__]

I never read anything official, but some stuff by framework makers (serverless/apex up)

edit: https://medium.com/@tjholowaychuk/aws-lambda-lifecycle-and-i...

[sologoub]

Thanks, but I think this is very different from connection pooling on a DB, say pdbouncer.

Doing some searching, I did find this that seems much closer: http://blog.rowanudell.com/database-connections-in-lambda/

TLDR; you can define the connection to DB outside of the scope of a given function, so it’s scoped to the container and can be reused so long as the container is not recycled. Seems promising!

[k__]

That's basically what I wrote