I found this reply from Amazon helpful.

TL;DR don't use a connection pool in Lambda

> Now I see that you mentioned in one of the github posts: "The Lambda does seem to use the pool, but if I make maybe 3 / 4 quick requests to the lambda, new connections are opened up despite there being all of those connections already."

> 3/4 quick requests would mean concurrent invocations, and concurrent invocations will execute in new containers. Containers are not aware of each other and cannot share state information so if an execution occurs in new container, it will open a new connection if there are none in this new container, despite there being existing connections from different containers. This can also cause your RDS instance to have too many open connections, because another container may have all the connections saturated, and if a new container is required to handle the load it may not be able to create the new RDS connection it needs to do it's work.

- https://github.com/sequelize/sequelize/issues/4938#issuecomm...

For most uses, database connection pooling (or, more accurately, keeping a connection per container), is the right practice to follow in Lambda. For many databases, creating a connection is expensive and slow, and amortizing those costs over multiple container uses (see https://aws.amazon.com/blogs/compute/container-reuse-in-lamb...) helps reduce latency and cost. Lambda allows you to configure a per-function concurrency limit, which you can use to make sure that the number of containers doesn't exceed your maximum database connections.

Lambdas are persistent so long as there is activity (ie it's "warm"). You can maintain a connection in a lambda and reuse it for subsequent calls. This isn't exactly the same as a connection pool, as you won't have multiplexing of any sort, but in practice you'll end up with 1 connection per concurrent request, which isn't too terrible, and if you keep the lambda warm there won't be any additional latency from having to connect.

Think of Lambda as one server per request, and pool (or not) accordingly. Each lambda container will only ever be serving one request at a time, but it may be reused to serve subsequent requests sequentially.

In that light, it might make sense to use a pool size of 1, if your application already does pooling. If you've written code to run multiple database queries simultaneously, you may want to adjust accordingly, but only allocate the number of connections you expect to use in that single request.

If you're connection constrained, you might want to look at pgBouncer, whether or not you're using Lambda. It increases your connection usage efficiency to the max irrespective of whether the connections are being used by lambda or a regular server.

You need to put a centralized pooler, such as pgbouncer, in front of your DB and have your lambdas connect to that.

Sounds like this person explains what you're asking for: http://blog.rowanudell.com/database-connections-in-lambda/

We are currently building the infrastructure for prismagraphql.com - a service that layers a GraphQL API over your existing databases. Lambda has some characteristics that would fit very well. We want to offer a service that:

- has a very low base cost - scales quickly to thousands of req/s

Operating this on lambda has some significant downsides:

- no request multiplexing - warm up overhead (lambda itself, our service, connections)

As we are operating at large scale we can invest in building infrastructure that supports this with more traditional AWS primitives.

In broad terms our approach is to:

- operate a t2.micro for each tenant - use burst capacity to bridge scale up periods - switch to c5 instances when a cluster reaches higher load.

This is a lot of operational overhead, but because we operate thousands of clusters we can fully automate this.

As a user of Prisma you can consume your database via a GraphQL API over http. This is a great benefit when developing serverless functions as Prisma essentially moves db connection pooling outside your serverless functions.