Can somone tell me how are we supposed to deal with things like "postgres connection pools" in a serverless world.
Do we need to open a new connection to the DB on every call?
Do we need to open a new connection to the DB on every call?
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...
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.
- 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.