Node.js PostgreSQL

Question

I saw a comment on a stackoverflow post by the package author ( What is the proper way to use the node.js postgresql module? ) saying that the best way is to use pg.connect each time. I was wondering if that method is different from the examples he mentioned on the npm website ( https://www.npmjs.com/package/pg )?

It seems to me if I follow your post on stackoverflow, then if there are 1000 database accesses by different clients during peak periods, then 1000 different database client connections will be created and there might be a risk of the database crashing (lack of RAM). Also, does this method (just using pg.connect each time) have a pool of connections where the connections are re-used and where there are only a maximum number of connections set by pg.defaults.poolSize. Please correct me if I am wrong?

Answer 1

In principle - yes. But keep in mind that the driver cannot do more than one query at the same time. That's the reason why multiple conenctions are recommended - but that can degrade performance for other reasons like too many sockets, max number of open connections of Postgres etc. Also, there are some problems that you may face that can be not that obvious but quite likely depending on your use case - see some relevant issues:

• pg.defaults.poolSize makes no difference. #931
• Suitable values for poolSize, poolIdleTimeout and reapIntervalMillis #1222
• pg.defaults.poolSize vs pg-pool #1102
• PG.connect never calls-back after (PG.defaults.poolSize) connections are used [6.0.3] #1085

Some modules that you may want to look at:

• pooled-pg - "A driver to PostgreSQL that is compatible with pg, with more effective pooling strategies."
• ppooled-pg - "Promisified PostgreSQL driver with more effective pooling strategies."

Answer 2

Making a new connection for every single query will generate an unnecessary overhead for every single query.

The proper way for using node.js postgres module is to have a connection pool and get a connection from the pool each time you want to query.

The reason is not because of database crashing for lack of ram. There is a maximum amount of connections that a postgres database can have open. The amount will be set in postgresql.conf and generally it's much lower than what would crash the ram (unless you deliberately set it to something ridiculous).

Keeping a connection pool up is good for a few things:

1. It decreases the response time because you don't spend unnecessary time opening (and closing) database connections.
2. You always know how many connections are open at a given time. You don't have connections waiting idly for 30 seconds or something like that before closing, even after you tell the connection to close.
3. The probability that you have unpredictable state in your application is significantly lower when you use a connection pool as opposed to opening a new connection for each query.

---

Also, I tend to allocate 80% of maximum number of connections to applications. 20% is reserved for replication stuff and the data team who need to query the database for their own work. Allocating 100% also may result in having unpredictable state in your application.