**Summary** Replaces per-account database connections with a shared pool in the billing service. Reduces connection count from ~1 per active account to a fixed pool of 20, fixing the connection-exhaustion errors seen during the Tuesday 9am sync. **What changed** - Replaced `BillingDBClient.__init__` per-account instantiation with a module-level `connection_pool` (asyncpg pool, max 20, min 5). - Changed `BillingDBClient` from owning a connection to acquiring from the pool inside each method via `async with pool.acquire()`. - Removed the `BillingDBClient.close()` calls in `accounts/service.py` since the pool now owns connection lifecycle. - Added pool metrics export to the existing Prometheus exporter (`billing_db_pool_in_use`, `billing_db_pool_idle`). **Why** Resolves BIL-2847. During Tuesday morning sync, connection count exceeded Postgres `max_connections` and new requests started failing with `connection refused`. Root cause: each `BillingDBClient` opened a dedicated connection and held it until garbage-collected, which under load meant ~1500 open connections against a ceiling of 1024. **Testing** - Ran the billing integration suite — all 47 tests pass. - Local load test with 200 concurrent simulated accounts; pool stays under 15 in use. - Did not test failover behavior of the pool itself; that's covered by asyncpg's existing tests but worth watching in staging. **Risks** If the pool size of 20 is too small for peak production load, this will queue requests rather than failing them, which presents as latency rather than errors. Watch `billing_db_pool_in_use` after deploy; if it sits at 20 for more than 30 seconds, increase the pool. **Notes for reviewer** The pool size of 20 is a starting point based on observed query latency (~15ms p50). If you have a different number in mind, let me know — it's a one-line change.