[gmac]

Right: at a basic level, using WebSockets lets us change as little as possible from the user perspective. You get an ordinary Postgres session with an ordinary Postgres driver, full control over transactions, and so on.

At this point, your serverless function establishes a new Postgres connection on each call. We do pooling on the server side with pgBouncer, which means we can handle lots of simultaneous connections (which is what this approach generates). It's true that this approach doesn't fully optimise for low latencies. But, as Nikita has mentioned elsewhere in this thread, we have a roadmap for bringing latency down in a number of different ways over time.

[Sujan]

Ok, so to make that explicit: If I want to do 5 parallel queries on my serverless function I should still have a connection pool size of 5 in my application, which will be fine as PgBouncer ensures there are plenty connections to open and use from the database server side. Correct?

[gmac]

In principle, yes, but as things stand you'll be starting 5 separate TLS connections to the server that way. My feeling is that this would be an unusual way to use serverless functions. Is it something you think you'd do?

[Sujan]

Yes. You only have to open these connections once on the first execution of that function (cold start), any future request that hit this warm function will have 5 open connections and can instantly execute these queries in parallel. No overhead at all to open the connections.

What would be the alternative? Only execute the queries in sequence, one by one?