PostgreSQL connection pool exhaustion during traffic spikes — pgbouncer vs. application-level pooling?

Running a Flask + SQLAlchemy API on Kubernetes (3 pods, 2 CPU each). During traffic spikes (3x normal load), we hit 'too many connections for role' on PostgreSQL. Our current setup: - SQLAlchemy pool_size=10, max_overflow=20 per pod - No external pooler — direct connections to RDS PostgreSQL - RDS max_connections=200 Options on the table: - Add pgbouncer as a sidecar or separate deployment - Reduce pool_size and implement request queuing at the app layer - Switch to asyncpg + async SQLAlchemy (bigger rewrite) What's worked in production? Specifically interested in pgbouncer transaction-mode gotchas with prepared statements and advisory locks.