Question :
Consider the mysql
package. The description covers connection pooling thus,
Rather than creating and managing connections one-by-one, this module
also provides built-in connection pooling using
mysql.createPool(config)
.
Then, there is the connection pool setting in proxysql
as described here.
Similarly, in case of PostgreSQL too, there is the pg
package supporting connection pooling and pgboucner
pooling feature.
- How are these approaches (
npm
package versus product supporting tools) different? - Ideally, I would like to configure connection pooling at the database level so that a developer is free from handling connections. Can this be a preferred approach?
Answer :
You can use connection pooling on any level, but I believe that it is best done with a connection pool inside the application server code for these reasons:
-
You don’t need an extra process like pgBouncer that you have start and monitor.
-
You don’t have any more TCP connections than necessary, thus conserving resources and being faster.
This holds if you have a single application server. If several of them access the same database, connecting pooling in the application server isn’t enough. It is still a goid idea if you want to limit the DB resources each one can use, but you will still need another connection pool to limit the total number of database connections.
Such a connection pool can be implemented in the database if the RDBMS supports it (PostgreSQL doesn’t), or it can be an external tool like pgBouncer.
Connection Pooling serves two particular purposes and both of them are client related.
First, pooling helps reduce the overhead of establishing connections.
Second, pooling helps conserve the TCP Port pool on the Client.
Most providers (e.g. SQLNCLI, ODBC) implement pooling on the client side and implement at least some features to allow the developer to control or influence the functioning.
IMO Server side connection pooling just wastes server resources.