[cavisne]

Another cool thing about this is it avoids the connection pool issue with Lambda (where concurrent requests cant reuse connections).

Aurora is already pretty good at handling a lot of connections but this is even better.

[keysmasher]

Not really, it was solved without this API given aurora serverless would manage connections and scaling automatically (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...).

But the real problem was connection time was unusable for any client facing application. I tried it after it was released (not preview). I really doubt this API would respond any faster.

[djhworld]

You can create a connection pool in a static context that lives throughout the lifetime of the JVM.

Although admittedly if Lambda scales to multiple JVMs as request rate increases, you'll have multiple pools. Or if your request rate is low you'll not get much benefit

[cavisne]

Lambda containers serve 1 request at a time, so the number of JVM's tends to scale out a lot quicker than you would expect. This is more of a broader problem with Java on lambda, as the classic Java way of creating a bunch of singletons on startup and accessing them from multiple threads doesn't work, you just get a really slow cold start time and some near empty connection pools.