NewYour coding agent can read the release notes before it upgrades.Set up the MCP server →
npm · #1462 most downloaded on npm
Connection pool for node-postgres
Last release 4 months ago
18 May 2026
Release timing varies
gaps range from 3 weeks to 9 months
Rarely documented
notes for 10 of 59 stable releases
Nothing withdrawn
no release was ever pulled
10 years old
61 releases · first in 2016
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
One column per quarter.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Include support for (parsing JSONB)[https://github.com/brianc/node-pg-types/pull/13] (supported in postgres 9.4)
Nothing published for this version
Nothing published for this version
Nothing published for this version
Include port as connection parameter to unix sockets
Nothing published for this version
Nothing published for this version
Nothing published for this version
Same changes to pg impact pg-pool as they both use the same connection parameter and connection string parsing code for configuring SSL.
pg impact pg-pool as they both use the same connection parameter and connection string parsing code for configuring SSL.Nothing published for this version
- Add maxUses config option.
…be returned in the client timezone. This is a breaking change, and if you use the date type you might want to examine your code and make sure nothing…
After some discussion it was decided node-postgres was non-compliant in how it was handling DATE results. They were being converted to UTC, but the PostgreSQL documentation specifies they should be returned in the client timezone. This is a breaking change, and if you use the date type you might want to examine your code and make sure nothing is impacted.
pg@v2.0 included changes to not convert large integers into their JavaScript number representation because of possibility for numeric precision loss. The same types in arrays were not taken into account. This fix applies the same type of type-coercion rules to arrays of those types, so there will be no more possible numeric loss on an array of very large int8s for example. This is a breaking change because now a return type from a query of int8[] will contain string representations
of the integers. Use your favorite JavaScript bignum module to represent them without precision loss, or punch over the type converter to return the old style arrays again.
Single date parameters were properly sent to the PostgreSQL server properly in local time, but an input array of dates was being changed into utc dates. This is a violation of what PostgreSQL expects. Small breaking change, but none-the-less something you should check out if you are inserting an array of dates.
This is a small change to bring the semantics of query more in line with other EventEmitters. The tests all passed after this change, but I suppose it could still be a breaking change in certain use cases. If you are doing clever things with the end and error events of a query object you might want to check to make sure its still behaving normally, though it is most likely not an issue.
The long & short of it is now any object you supply in the list of query values will be inspected for a .toPostgres method. If the method is present it will be called and its result used as the raw text value sent to PostgreSQL for that value. This allows the same type of custom type coercion on query parameters as was previously afforded to query result values.
If domains are active node-postgres will honor them and do everything it can to ensure all callbacks are properly fired in the active domain. If you have tried to use domains with node-postgres (or many other modules which pool long lived event emitters) you may have run into an issue where the active domain changes before and after a callback. This has been a longstanding footgun within node-postgres and I am happy to get it fixed.
Avoids a scenario where your pool could fill up with disconnected & unusable clients.
To provide better documentation and a clearer explanation of how to override the query result parsing system we broke the type converters into their own module. There is still work around removing the 'global-ness' of the type converters so each query or connection can return types differently, but this is a good first step and allow a lot more obvious way to return int8 results as JavaScript numbers, for example
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Properly handle various PostgreSQL to JavaScript type conversions to avoid data loss:
PostgreSQL | pg@v2.0 JavaScript | pg@v1.0 JavaScript
--------------------------------|----------------
float4 | number (float) | string
float8 | number (float) | string
int8 | string | number (int)
numeric | string | number (float)
decimal | string | number (float)
For more information see https://github.com/brianc/node-postgres/pull/353 If you are unhappy with these changes you can always override the built in type parsing fairly easily.
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Nothing published for this version
Make client_encoding configurable and optional
Nothing published for this version
return field metadata on result object: access via result.fields[i].name/dataTypeID
built in support for JSON data type for PostgreSQL Server @ v9.2.0 or greater
JSON data type for PostgreSQL Server @ v9.2.0 or greaterNothing published for this version
Nothing published for this version
Nothing published for this version
remove deprecated functionality
pg.connect now requires 3 argumentsStringNothing published for this version
Nothing published for this version
Your coding agent can read these notes before it upgrades. Set up the MCP server →