Query pipelining has shipped as an opt-in feature in pg 8.23.0 and pg-native 3.9.0 (released August 8, 2026, via PR #3652), letting node-postgres send multiple queries without waiting for each response. Enabling it via a single 'pipeline: true' option delivers 2-3x throughput gains in benchmarks: simple queries jump from ~10,746 to 25,294 qps with the JS client, and parameterized queries improve similarly with pg-native. The feature works with named prepared statements (avoiding duplicate Parse messages), pools, PgBouncer (all modes, with 1.21.0+ needed for named statement re-preparation), and graceful shutdown. It's best suited for independent queries like multi-table page loads or batch inserts, not for queries that depend on each other's results.
Table of contents
What it looks likeHow it works internallyBenchmarksNamed prepared statementsPool integrationNative client supportPgBouncer compatibilityGraceful shutdown💡 When to use itTry itQuestions this post answers
How do I enable query pipelining in node-postgres and what version do I need?
Install pg 8.23.0 or later and pass pipeline: true when creating a Client or Pool. No new API is required; all query types (plain text, parameterized, named prepared statements) work with the existing client.query() and Promise.all pattern. Pipelining is off by default, so upgrading alone changes nothing until the flag is set. For the native client, install pg-native 3.9.0 or later, which requires PostgreSQL 14+ client libraries. Developers upgrading their PostgreSQL client stack can track library changes like this one on daily.dev.
Does node-postgres pipelining work with PgBouncer?
Yes, pipelining works with PgBouncer in session, transaction, and statement pool modes. PgBouncer has tracked outstanding pipeline requests by counting Sync messages since version 1.7 (December 2015) and only releases the server connection after all responses are delivered. For named prepared statements through PgBouncer in transaction or statement mode, PgBouncer 1.21.0 or newer is required for automatic re-preparation support. Teams running PgBouncer in production can weigh compatibility details like these on daily.dev before rolling out pipelining.
Why is the native pg-native client faster than the JS pg client for parameterized pipelined queries but slower for simple queries?
For simple queries the pure JavaScript client is faster (25,294 qps vs 21,524 qps) because crossing from JavaScript to C++ for each query adds more overhead than native parsing saves. For parameterized queries, pg-native is faster (20,792 qps vs 14,226 qps) because libpq's pipeline mode batches queries in C and avoids crossing the JS/C++ boundary for each individual query. Developers choosing between JS and native PostgreSQL clients can compare benchmarks like these on daily.dev.