CodeParkStart from the database, not the app. Add up the pools of all instances. The total must stay under max_connections, the database's limit on open connections. Also leave room for migrations, admin sessions and replicas. For example, 8 instances with a pool of 50 each need 400 connections. That is far too many for most servers.
Bigger pools are not faster. The database can only run as many queries in parallel as its CPU cores and disk throughput allow. Past that point, extra connections only add costs:
- Context switching: the CPU keeps jumping between busy connections.
- Lock contention: more queries wait for the same locks.
A small pool with a queue usually gives better latency than a large one. A common starting point is a small multiple of the database's CPU core count in total. Split that total across the instances, then tune it with load tests.
Watch two numbers: pool wait time and database CPU. If you need many instances, put a pooler like PgBouncer in front of the database. A pooler is a proxy that lets many app connections share a few real database connections, so app-side connections become cheap.
- The sum of all pools stays below max_connections, with some room to spare.
- Throughput is limited by the database's CPU cores and disk I/O.
- Pools that are too big increase contention.
- Start small, measure, then tune.
- Use an external pooler when you have many instances.