Hacker News new | ask | show | jobs
by pastaking 3398 days ago
How do you use database connection pools with lambda? I thought it wasn't possible.
1 comments

AWS will sometimes reuse the container in which your Lambda runs, so if you set up e.g., database pools during load time, they're often still there the next time.

Related: https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...

Yes, but there's no guarantee that lambda will reuse a connection / won't continue to request new connections against your database :( Currently, it seems like there's no "concurrency limit" or "per-function throttling". It would be amazing if requests are just magically queued up in SQS and lambda just processes them... like a traditional queue-worker system except now we don't have to manage the infra.
That's essentially how asynchronously invoked (e.g., triggered by an event in S3 or DynamoDB) lambda tasks work. They're retried if the original invocation doesn't execute successfully, and if the third try fails, the triggering event is sent to a dead letter queue in SQS.
I'm not familiar at all with Amazon's cloud, so I might be misinterpreting... but when you say "sometimes reuse..." and "they're often still there..." it sounds to me like they might as well not be? How would that be a good foundation for an app deployed in Lambda?
Think of Lambdas like autoscaling containers. If you're operating with decent load, there's a good chance your container will stay up and be reused for multiple requests. But if load drops, your containers might be shut down so they aren't taking up resources while they're not being used. When load increases again, more instances will be spun up.

It's the same approach as autoscaling VMs, but at a function level.

If the pool is still there, it gets reused. If not, a new one is created.

It should help with overhead, but not always. There's benefits to partial solutions sometimes, if you can avoid the side effects.

Right, but only one request can be in progress against a container at a time, correct? So there's no reason for your pool to allow more than one connection. Of course, that might still be useful for retry, etc. if the connection went away while the container was frozen.
It would be a pool of just one connection per database endpoint. So pool in the sense that once a stateless function is done with it it becomes available again for another function to take it. But you don't need multiple connections of the same type in the pool.