Skip to content

Deprecations #3510

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Jul 17, 2025
Merged

Deprecations #3510

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d995350
Make active query a private prop
Jul 16, 2025
6d3449c
Make client.queryQueue private (with deprecation)
brianc Jul 16, 2025
00a44a8
Deprecate some legacy features
brianc Jul 16, 2025
26b5a94
Update packages/pg/lib/client.js
brianc Jul 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
108 changes: 45 additions & 63 deletions packages/pg-pool/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,9 +1,11 @@
# pg-pool

[![Build Status](https://travis-ci.org/brianc/node-pg-pool.svg?branch=master)](https://travis-ci.org/brianc/node-pg-pool)

A connection pool for node-postgres

## install

```sh
npm i pg-pool pg
```
Expand Down Expand Up @@ -48,25 +50,26 @@ const pgNativePool = new Pool({ Client: PgNativeClient })
```

##### Note:

The Pool constructor does not support passing a Database URL as the parameter. To use pg-pool on heroku, for example, you need to parse the URL into a config object. Here is an example of how to parse a Database URL.

```js
const Pool = require('pg-pool');
const Pool = require('pg-pool')
const url = require('url')

const params = url.parse(process.env.DATABASE_URL);
const auth = params.auth.split(':');
const params = url.parse(process.env.DATABASE_URL)
const auth = params.auth.split(':')

const config = {
user: auth[0],
password: auth[1],
host: params.hostname,
port: params.port,
database: params.pathname.split('/')[1],
ssl: true
};
ssl: true,
}

const pool = new Pool(config);
const pool = new Pool(config)

/*
Transforms, 'postgres://DBuser:secret@DBHost:#####/myDB', into
Expand All @@ -79,23 +82,25 @@ const pool = new Pool(config);
ssl: true
}
*/
```
```

### acquire clients with a promise

pg-pool supports a fully promise-based api for acquiring clients

```js
const pool = new Pool()
pool.connect().then(client => {
client.query('select $1::text as name', ['pg-pool']).then(res => {
client.release()
console.log('hello from', res.rows[0].name)
})
.catch(e => {
client.release()
console.error('query error', e.message, e.stack)
})
pool.connect().then((client) => {
client
.query('select $1::text as name', ['pg-pool'])
.then((res) => {
client.release()
console.log('hello from', res.rows[0].name)
})
.catch((e) => {
client.release()
console.error('query error', e.message, e.stack)
})
})
```

Expand All @@ -105,7 +110,7 @@ this ends up looking much nicer if you're using [co](https://github.com/tj/co) o

```js
// with async/await
(async () => {
;(async () => {
const pool = new Pool()
const client = await pool.connect()
try {
Expand All @@ -114,18 +119,18 @@ this ends up looking much nicer if you're using [co](https://github.com/tj/co) o
} finally {
client.release()
}
})().catch(e => console.error(e.message, e.stack))
})().catch((e) => console.error(e.message, e.stack))

// with co
co(function * () {
co(function* () {
const client = yield pool.connect()
try {
const result = yield client.query('select $1::text as name', ['brianc'])
console.log('hello from', result.rows[0])
} finally {
client.release()
}
}).catch(e => console.error(e.message, e.stack))
}).catch((e) => console.error(e.message, e.stack))
```

### your new favorite helper method
Expand All @@ -148,14 +153,14 @@ pool.query('SELECT $1::text as name', ['brianc'], function (err, res) {
})
```

__pro tip:__ unless you need to run a transaction (which requires a single client for multiple queries) or you
**pro tip:** unless you need to run a transaction (which requires a single client for multiple queries) or you
have some other edge case like [streaming rows](https://github.com/brianc/node-pg-query-stream) or using a [cursor](https://github.com/brianc/node-pg-cursor)
you should almost always just use `pool.query`. Its easy, it does the right thing :tm:, and wont ever forget to return
you should almost always just use `pool.query`. Its easy, it does the right thing :tm:, and wont ever forget to return
clients back to the pool after the query is done.

### drop-in backwards compatible

pg-pool still and will always support the traditional callback api for acquiring a client. This is the exact API node-postgres has shipped with for years:
pg-pool still and will always support the traditional callback api for acquiring a client. This is the exact API node-postgres has shipped with for years:

```js
const pool = new Pool()
Expand All @@ -175,7 +180,7 @@ pool.connect((err, client, done) => {
### shut it down

When you are finished with the pool if all the clients are idle the pool will close them after `config.idleTimeoutMillis` and your app
will shutdown gracefully. If you don't want to wait for the timeout you can end the pool as follows:
will shutdown gracefully. If you don't want to wait for the timeout you can end the pool as follows:

```js
const pool = new Pool()
Expand All @@ -187,7 +192,7 @@ await pool.end()

### a note on instances

The pool should be a __long-lived object__ in your application. Generally you'll want to instantiate one pool when your app starts up and use the same instance of the pool throughout the lifetime of your application. If you are frequently creating a new pool within your code you likely don't have your pool initialization code in the correct place. Example:
The pool should be a **long-lived object** in your application. Generally you'll want to instantiate one pool when your app starts up and use the same instance of the pool throughout the lifetime of your application. If you are frequently creating a new pool within your code you likely don't have your pool initialization code in the correct place. Example:

```js
// assume this is a file in your program at ./your-app/lib/db.js
Expand Down Expand Up @@ -215,11 +220,11 @@ module.exports.connect = () => {

### events

Every instance of a `Pool` is an event emitter. These instances emit the following events:
Every instance of a `Pool` is an event emitter. These instances emit the following events:

#### error

Emitted whenever an idle client in the pool encounters an error. This is common when your PostgreSQL server shuts down, reboots, or a network partition otherwise causes it to become unavailable while your pool has connected clients.
Emitted whenever an idle client in the pool encounters an error. This is common when your PostgreSQL server shuts down, reboots, or a network partition otherwise causes it to become unavailable while your pool has connected clients.

Example:

Expand All @@ -229,15 +234,15 @@ const pool = new Pool()

// attach an error handler to the pool for when a connected, idle client
// receives an error by being disconnected, etc
pool.on('error', function(error, client) {
pool.on('error', function (error, client) {
// handle this in the same way you would treat process.on('uncaughtException')
// it is supplied the error as well as the idle client which received the error
})
```

#### connect

Fired whenever the pool creates a __new__ `pg.Client` instance and successfully connects it to the backend.
Fired whenever the pool creates a **new** `pg.Client` instance and successfully connects it to the backend.

Example:

Expand All @@ -247,20 +252,19 @@ const pool = new Pool()

const count = 0

pool.on('connect', client => {
pool.on('connect', (client) => {
client.count = count++
})

pool
.connect()
.then(client => {
.then((client) => {
return client
.query('SELECT $1::int AS "clientCount"', [client.count])
.then(res => console.log(res.rows[0].clientCount)) // outputs 0
.then((res) => console.log(res.rows[0].clientCount)) // outputs 0
.then(() => client)
})
.then(client => client.release())

.then((client) => client.release())
```

#### acquire
Expand Down Expand Up @@ -293,12 +297,11 @@ setTimeout(function () {
console.log('connect count:', connectCount) // output: connect count: 10
console.log('acquire count:', acquireCount) // output: acquire count: 200
}, 100)

```

### environment variables

pg-pool & node-postgres support some of the same environment variables as `psql` supports. The most common are:
pg-pool & node-postgres support some of the same environment variables as `psql` supports. The most common are:

```
PGDATABASE=my_db
Expand All @@ -308,40 +311,19 @@ PGPORT=5432
PGSSLMODE=require
```

Usually I will export these into my local environment via a `.env` file with environment settings or export them in `~/.bash_profile` or something similar. This way I get configurability which works with both the postgres suite of tools (`psql`, `pg_dump`, `pg_restore`) and node, I can vary the environment variables locally and in production, and it supports the concept of a [12-factor app](http://12factor.net/) out of the box.

## bring your own promise

In versions of node `<=0.12.x` there is no native promise implementation available globally. You can polyfill the promise globally like this:

```js
// first run `npm install promise-polyfill --save
if (typeof Promise == 'undefined') {
global.Promise = require('promise-polyfill')
}
```

You can use any other promise implementation you'd like. The pool also allows you to configure the promise implementation on a per-pool level:

```js
const bluebirdPool = new Pool({
Promise: require('bluebird')
})
```

__please note:__ in node `<=0.12.x` the pool will throw if you do not provide a promise constructor in one of the two ways mentioned above. In node `>=4.0.0` the pool will use the native promise implementation by default; however, the two methods above still allow you to "bring your own."
Usually I will export these into my local environment via a `.env` file with environment settings or export them in `~/.bash_profile` or something similar. This way I get configurability which works with both the postgres suite of tools (`psql`, `pg_dump`, `pg_restore`) and node, I can vary the environment variables locally and in production, and it supports the concept of a [12-factor app](http://12factor.net/) out of the box.

## maxUses and read-replica autoscaling (e.g. AWS Aurora)

The maxUses config option can help an application instance rebalance load against a replica set that has been auto-scaled after the connection pool is already full of healthy connections.

The mechanism here is that a connection is considered "expended" after it has been acquired and released `maxUses` number of times. Depending on the load on your system, this means there will be an approximate time in which any given connection will live, thus creating a window for rebalancing.
The mechanism here is that a connection is considered "expended" after it has been acquired and released `maxUses` number of times. Depending on the load on your system, this means there will be an approximate time in which any given connection will live, thus creating a window for rebalancing.

Imagine a scenario where you have 10 app instances providing an API running against a replica cluster of 3 that are accessed via a round-robin DNS entry. Each instance runs a connection pool size of 20. With an ambient load of 50 requests per second, the connection pool will likely fill up in a few minutes with healthy connections.
Imagine a scenario where you have 10 app instances providing an API running against a replica cluster of 3 that are accessed via a round-robin DNS entry. Each instance runs a connection pool size of 20. With an ambient load of 50 requests per second, the connection pool will likely fill up in a few minutes with healthy connections.

If you have weekly bursts of traffic which peak at 1,000 requests per second, you might want to grow your replicas to 10 during this period. Without setting `maxUses`, the new replicas will not be adopted by the app servers without an intervention -- namely, restarting each in turn in order to build up new connection pools that are balanced against all the replicas. Adding additional app server instances will help to some extent because they will adopt all the replicas in an even way, but the initial app servers will continue to focus additional load on the original replicas.
If you have weekly bursts of traffic which peak at 1,000 requests per second, you might want to grow your replicas to 10 during this period. Without setting `maxUses`, the new replicas will not be adopted by the app servers without an intervention -- namely, restarting each in turn in order to build up new connection pools that are balanced against all the replicas. Adding additional app server instances will help to some extent because they will adopt all the replicas in an even way, but the initial app servers will continue to focus additional load on the original replicas.

This is where the `maxUses` configuration option comes into play. Setting `maxUses` to 7500 will ensure that over a period of 30 minutes or so the new replicas will be adopted as the pre-existing connections are closed and replaced with new ones, thus creating a window for eventual balance.
This is where the `maxUses` configuration option comes into play. Setting `maxUses` to 7500 will ensure that over a period of 30 minutes or so the new replicas will be adopted as the pre-existing connections are closed and replaced with new ones, thus creating a window for eventual balance.

You'll want to test based on your own scenarios, but one way to make a first guess at `maxUses` is to identify an acceptable window for rebalancing and then solve for the value:

Expand All @@ -362,7 +344,7 @@ To run tests clone the repo, `npm i` in the working dir, and then run `npm test`

## contributions

I love contributions. Please make sure they have tests, and submit a PR. If you're not sure if the issue is worth it or will be accepted it never hurts to open an issue to begin the conversation. If you're interested in keeping up with node-postgres releated stuff, you can follow me on twitter at [@briancarlson](https://twitter.com/briancarlson) - I generally announce any noteworthy updates there.
I love contributions. Please make sure they have tests, and submit a PR. If you're not sure if the issue is worth it or will be accepted it never hurts to open an issue to begin the conversation. If you're interested in keeping up with node-postgres releated stuff, you can follow me on twitter at [@briancarlson](https://twitter.com/briancarlson) - I generally announce any noteworthy updates there.

## license

Expand Down
42 changes: 0 additions & 42 deletions packages/pg-pool/test/bring-your-own-promise.js
View file
Open in desktop

This file was deleted.

Loading