Great point, @porsager. Let me specify this to connection pooling guidance.

Oh - you can do const sql = postgres() at the top level if that looks better for you. Even have it in an imported file as suggested in the docs. Postgres.js is lazy, so no connection happens until you actually make a query 👍

Ah, I see. I had assumed that after calling sql.end() the instance could no longer be used.

By the way, I tried this and it was as I suspected. Declaring sql at the top level and then calling sql.end() in the handler resulted in a 'CONNECTION_ENDED' error on the next invocation.

Well that must mean the same instance is handling several requests, so why end the connection?

It comes back to my original question really. I'm not sure if it's safe to keep database connections open between requests. Lambda reuse is non-deterministic and my understanding is that this point I raised could be a concern:

With lambda, there is the risk of zombie connections if they are kept alive between invocations because of the freeze/thaw process.

I could be wrong though. If connections can survive the freeze/thaw process without issue then keeping the connections open makes sense. There is quite a lot of conflicting advice out there so I'm just reaching out for clarity on the best approach.

ah I see.

I think the only sane approach would be doing actual benchmarks. I can't imagine it would make sense to close the connection after each request tbh. A low idle timeout of 1 second sounds reasonable

@jamesopstad what did you end up deciding?