We are hitting "Too Many Connections" errors on our RDS Postgres instance during traffic spikes because our Lambda functions don't share a connection pool. We’ve tried RDS Proxy, but the latency overhead is noticeable. Is there a better way to manage database scaling for serverless apps in 2024?
3 answers
RDS Proxy is usually the standard answer, but if you're sensitive to that extra 10-15ms of latency, you might want to look at a "Connection Concentrator" like PgBouncer sitting on a small EC2 instance, though that adds management. Alternatively, have you considered moving to a truly serverless database like Aurora Serverless v2 or DynamoDB? Aurora v2 handles the scaling much more gracefully than a traditional RDS instance. We actually moved our high-frequency write operations to DynamoDB and kept the relational data in RDS, which significantly reduced the connection pressure.
Are you using a specific ORM like Prisma or TypeORM? Some of them have "Serverless-friendly" modes that help manage connections more efficiently.
Sometimes the simplest solution is just to scale up the RDS instance size to get a higher max_connections limit. It’s brute force, but it works if you have the budget.
Sarah is right, but it's an expensive band-aid. We found that optimizing our Lambda execution time actually helped more, as it freed up the connections faster for the next request.
Kevin, we are using Prisma. We actually found that the "Prisma Data Proxy" helped quite a bit with connection management without the complexity of AWS's native proxy. However, we eventually realized our Lambdas were staying "warm" too long and not releasing connections. We adjusted the idle_timeout in the DB settings, which cleared up the hanging connections. It’s a bit of a balancing act between Lambda warm-up speed and DB connection limits.