Configuring the Connection Pool

`MaxOpenConns`

By default: postgres has hard limit of 100 open connections
Returns an “sorry, too many clients already” error when that limit is hit
Why should set our own limit?
- It acts like a throttle and prevents the db from being swamped by a huge number of tasks all at once.
Limitations to setting our own limit:
- The request could “hang” indefinitely.
- This means that we will need to set a timeout on database tasks.

`MaxIdleConns`

Sets a limit on the number of idle connections in the pool
Default = 2
Higher number of idle connections in the pool will improve performance but the downside is that it takes up memory that could be used for the application and database instead.
Setting a too high max idle connections may result in connections becoming unusuable and more resources being used.
Limit should always be <= MaxOpenConns

`ConnMaxLifetime`

Sets the max length of time a connection can be reused for.
Default: no max lifetime and connections will be reused forever
Leaving it unlimited will help performance because it makes it less likely that new connections will need to be created .
Shorter lifetime can help facilitate swapping databases gracefully beind a load balancer.

`ConnMaxIdleTime`

Sets the maximum length of time that a connection can be idle for before it is marked expired
Default: no limit

TLDR;

MaxOpenConns should always be explicitly set comfortable below any hard limits set by the database itself. Consider keeping it low for rudimentary throttling. A limit of 25 connections is a nice starting point for small to medium web applications.

In general, a higher MaxOpenConns and MaxIdleConns value equals better performance but has diminishing returns. A too large idle connection pool can lead reduced performance and unnecessary resource consumption

ConnMaxIdleTime should be set to remove idle connections that haven’t been used in a long time.

ConnMaxLifetime should be ok as unlimited unless the database imposes a hard limit on connection lifetime.