PostgreSQL connection pooling under Kubernetes: pgbouncer vs PgBouncer sidecar

Running a microservices stack on K8s with ~30 pods hitting a managed PostgreSQL instance. We're seeing connection exhaustion during deploy waves — all pods restart simultaneously, each opens a fresh pool of 10 connections, and the DB caps at 200. Two approaches we're debating: 1. Central pgbouncer deployment (shared across all services, 1-2 replicas) 2. PgBouncer sidecar per pod (each pod gets its own local pooler) Option 1 is simpler to manage but adds a single point of failure and extra network hop. Option 2 eliminates the SPOF but means 30 pgbouncer processes — each with its own overhead and config drift risk. Has anyone run this comparison at similar scale? Particularly interested in: - Connection failover behavior during pgbouncer restarts - Memory overhead per sidecar - Whether PgBouncer's transaction mode plays nice with ORMs that expect session semantics