feat(db): Database connection multiplexing for serverless environments (#600)

[jadonamite]

Summary

Implements database connection multiplexing for serverless workloads. Serverless functions (webhook handlers, auth callbacks, scheduled jobs) currently open a new DB connection per invocation, exhausting the connection limit during traffic spikes. This routes all connections through a transaction-pooling proxy (AWS RDS Proxy or self-hosted PgBouncer), so a small set of backend connections is multiplexed across hundreds of concurrent functions.

Changes

• backend/shared/db/serverlessPool.ts — ServerlessConnectionPool: transaction-pooling adapter over the existing pg pool, with withClient/withTransaction/query helpers, IAM and SCRAM-256 auth modes, per-connect credential refresh (rotating RDS tokens), and connection-leak detection that force-closes any client checked out longer than 30s.
• backend/serverless/dbConfig.ts — env-driven pool configuration, including an RDS IAM auth-token credential provider (@aws-sdk/rds-signer, lazily imported).
• backend/serverless/withDatabase.ts — Lambda handler wrapper that hands each invocation a pooled client and calls release() in a finally block, regardless of success/throw. Pool singleton is reused across warm invocations.
• backend/monitoring/connectionPoolMetrics.ts — Prometheus pool gauges (total/idle/waiting/checked-out), a *_leaked_total counter, and structured leak alerting.
• infra/terraform/rds_proxy.tf — RDS Proxy with IAM auth, transaction pooling (~50 backend connections), TLS required, 30s idle timeout, EXCLUDE_VARIABLE_SETS pinning filter.
• infra/terraform/pgbouncer.tf — self-hosted PgBouncer alternative (transaction mode, SCRAM-256, MAX_PREPARED_STATEMENTS, 500 client cap / 50 server pool).
• docker-compose.yml — local Postgres + PgBouncer for dev/test parity.

Acceptance criteria

• PgBouncer deployment (docker-compose + Terraform) or RDS Proxy configuration
• Transaction pooling mode: connections reused across invocations
• Prepared-statement support (PgBouncer MAX_PREPARED_STATEMENTS / RDS Proxy)
• Authentication: IAM-based (AWS RDS) or SCRAM-256 (self-hosted)
• Connection limits: max ~50 pooled connections serving 500+ concurrent functions
• Lambda handler adaptation: release() in a finally block per invocation
• Edge case: connection-leak detection (abandoned >30s, log and force-close)

Closes #600

[drips-wave]

@jadonamite Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

Since your pull request originates from a forked repository, GitGuardian is not able to associate the secrets uncovered with secret incidents on your GitGuardian dashboard.
Skipping this check run and merging your pull request will create secret incidents on your GitGuardian dashboard.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
-	-	Generic Password	7167381	docker-compose.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}