Per-Tenant Connection Pools as TTL Caches: Capacity and Cold-Start Trade-offs in Database-per-Tenant PostgreSQL

On PostgreSQL a connection serves one database, so a replicated service with a database per tenant keeps a pool per tenant on every replica. We model these pools as time-to-live (TTL) caches: a tenant-replica pair holds a connection only while its last request is younger than the pool's idle timeout plus housekeeping delay. Capacity: with a zero minimum idle size, expected tenant connections are at most total request rate times mean retention time, whatever the tenant count (measured: 100 to 10,000); with HikariCP's default positive minimum, they grow with every provisioned tenant. Cold starts: the same retention time sets the share of requests opening a connection, 66% at 2 req/s with a 30 s timeout under long-tailed popularity. Routing each tenant to one replica beats a longer timeout: it matches the cold-start share of a fourfold timeout with a third of its connections. The model predicted every pooler-free configuration mean on minikube and Amazon EKS within 4%, measured cold-start shares within 5 points, and the tenant at which HikariCP's defaults exhaust an Amazon RDS db.t4g.medium. Proxy poolers at their defaults multiply the count. Autovacuum CPU binds next, near 1500 idle databases on RDS. We derive rules for pools, timeouts, routing and poolers.