Hey everyone,
I'm exploring the best practices for managing connections between AWS Lambda and DSQL. I noticed that it doesn't support RDS Proxy or the Data API, which really limits my options. I'm trying to decide between these two approaches:
1. Opening and closing a new connection for each invocation. This would help prevent connection leaks, but it adds latency.
2. Keeping a connection open, which could reduce latency but risks leaving connections open if they aren't properly closed.
Does DSQL handle option 2 well? Maybe it has some kind of internal proxy? If not, how significant is the latency issue with option 1?
Thanks for your insights!
1 Answer
When working with Lambda and DSQL, the common approach is to open and close connections per invocation since there’s no managed proxy available right now. You can sometimes reuse connections within the same container's lifecycle, but don’t rely on that for across-invocation connections. DSQL can handle short-lived bursts quite well, just be mindful of idle timeouts and try to batch queries to minimize latency.
I get that! But why can’t connections last between invocations? I’m not super familiar with the PSQL protocol, but I think I saw some code suggesting we could create a connection proxy that handles reconnections automatically. What’s your take on that?