Benchmarks
This report runs under Node.js. The same suite also runs under Bun — see Benchmarks (Bun), kept as a separate report rather than merged into this one, since GC instrumentation, cursor streaming, and binary-format control all differ enough between the two runtimes that a single table would conflate a library difference with a runtime difference.
Generated by npm run bench:report. Do not hand-edit — re-run the command instead.
Contents
- Methodology
- Environment
- Connection
- Simple Query
- Extended Query
- Unit of Work
- Bulk Load
- Cursor Streaming
- Connection Pooling
- Raw data
Methodology
These numbers come from benchmark/ (npm run bench), comparing PostgreJS against pg (node-postgres) and postgres (postgres.js) against the same server, on the same machine, with the same workload. Each scenario is written once per library, using that library's own fastest calling convention - only the mechanism differs, never the work. benchmark/README.md says how to reproduce them.
Each (library, scenario) pair runs in a child process of its own, one at a time, three times over; the tables report the median of the three.
Reading a table
Rows are in a fixed library order rather than fastest-first, so a library sits in the same place in every scenario. A bolded value is the best one or tied with it - the tie band is how far the leader's own repeats of that column moved, so nothing is called slower than the noise the leader itself shows.
What survives a re-run is the ordering, not the absolute numbers: the same scenario on the same machine, hours later, has been seen to move by 2x. Read a row against the rows beside it, and not against a table of another date.
The columns
| Column | What it answers |
|---|---|
GC (ms/op) | Time spent collecting, per call - how much garbage the library's own path makes. |
Peak Heap (KB) | The most heapUsed + external ever stood above a forced-GC baseline during the run. Not what one call needs: it also holds whatever earlier calls left uncollected. external counts because the payload usually lives there - a Buffer, and a large string built from one, are both off-heap. |
Retained (KB) | What is still held once the run ends. A working set, not a footprint: left idle, both this client's buffers and the others' pools fall back to nothing within seconds. |
Net in/out (KB/op) | Bytes across the socket each way. Only on the four scenarios whose payload is the point - the two large fetches and the two Bulk Loads - since everywhere else it is small and identical across libraries. |
Memory figures are noisier than latency ones; read them as a direction rather than to their last digit. Under Bun, GC (ms/op) is blank: PerformanceObserver never reports a gc entry there. Peak Heap is unaffected.
Where the comparison is not like-for-like
Deliberate, and worth knowing before reading a row:
- Cursor streaming:
pghas no cursor API of its own, so its scenario emulates one withDECLARE/FETCH. - Bulk Load (binary COPY) has one row: only this client can produce the format. Read it against Bulk Load (text COPY), where all three format the same CSV and the ranking is a ranking of drivers.
- Row shape: PostgreJS is set to
objectRows: trueeverywhere so its rows match what the others return by default. The one normalisation in the suite. - Type decoding: no custom parsers or overrides anywhere - each library decodes as it does out of the box, which is what a caller gets.
- Pooling, pipelining and prepared statements: each library uses its own mechanism and its own defaults. The numbers compare libraries as they ship, not one dial turned for all three.
- One PostgreJS default is turned off:
asyncErrorHandling, which captures a caller-preserving async stack on every call so a failure points at the line that made it.pgandpostgres.jshave no equivalent, so leaving it on would charge one library for a feature the others do not offer. It stays on by default in the library; it is off only here, and it is worth about 0.5-1.0 KB a call on a small statement. pg-nativeis out of scope: it needs a system libpq and native compilation, which CI cannot assume. It could be added later behind its own flag.- A scenario that needs more warmup or more repeats than the rest says so in its own description.
Environment
- Run date: 2026-10-05T17:29:57.699Z
- Runtime: Node.js v24.15.0
- OS: Darwin 25.6.0 (darwin/arm64)
- CPU: Apple M5 Pro (18 logical cores)
- RAM: 48.0 GB total
- PostgreSQL: PostgreSQL 18.6 on aarch64-unknown-linux-musl, compiled by gcc (Alpine 15.2.0) 15.2.0, 64-bit
- Library versions (installed, not this repo's semver range): pg (node-postgres) 8.23.0, PostgreJS 3.12.0, postgres (postgres.js) 3.4.9
Connection
The fixed cost of opening (and closing) a connection - the TCP handshake, PostgreSQL startup/auth handshake, and ReadyForQuery, paid once per connection lifetime rather than once per query.
Connect
Open a fresh connection/session and close it, repeated per sample
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 2.085 | 2.112 | 2.638 | 485.5 | 3.96x | 0.0114 | 6089.11 | 1074.50 |
| pg (node-postgres) (8.23.0) | 3.094 | 3.141 | 4.196 | 326.4 | 2.67x | 0.0126 | 4246.98 | 1207.57 |
| postgres (postgres.js) (3.4.9) | 8.260 | 8.634 | 10.367 | 121.7 | 1.00x | 0.1133 | 14785.92 | 1084.07 |
Simple Query
PostgreSQL's Simple Query sub-protocol: the client sends the SQL text as a single Query (Q) message and the server parses, plans, executes, and streams the results back in that same round trip - no separate parse/bind/describe/execute/sync steps, and no query parameters. In postgrejs this is Connection.execute(sql). It's the cheapest way to run a query the client isn't going to reuse, which is why it's also the baseline every other protocol group below is compared against. It's distinct from the Extended Query group below: Extended Query trades this single round trip for several (parse, bind, describe, execute, sync) in exchange for bind parameters and a statement the server can plan once and re-execute. The scenarios here measure that Simple Query round trip three ways: a single query on an otherwise-idle connection, many queries fired concurrently over one connection, and one query that fetches many rows.
Sequential Execution
Run select 1 one call at a time on an already-open connection.
Each call is fully awaited before the next one starts.
Every library uses its genuine Simple Query path: PostgreJS's execute(), pg's query(text) with no params, postgres.js's unsafe() with no args - always a real Simple Query message, regardless of any prepare option.
This is the baseline for the group: one round trip's plain cost, with no concurrency, no pooling, and no bind parameters. Compare it against Concurrent Execution below to see what overlapping calls on the same connection buys each library.
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 0.195 | 0.197 | 0.324 | 5208.8 | 1.02x | 0.0007 | 9190.91 | 736.17 |
| pg (node-postgres) (8.23.0) | 0.197 | 0.199 | 0.329 | 5160.0 | 1.01x | 0.0009 | 17343.72 | 735.97 |
| postgres (postgres.js) (3.4.9) | 0.199 | 0.201 | 0.332 | 5115.7 | 1.00x | 0.0010 | 14614.29 | 954.84 |
Concurrent Execution
The concurrent counterpart to Sequential Execution above. Fire 100 Simple Query calls on the SAME already-open connection without awaiting each one individually, then await them all via Promise.all().
PostgreJS pipelines these at the wire level: it writes each message without waiting for the previous one's response, then matches responses back in FIFO order, so results never cross-talk even though the caller never awaited between calls.
Each call selects a distinct literal and checks the result against it, so this scenario verifies correctness too - do the other libraries' single connections queue/pipeline correctly? - not just timing. Without distinct values every response would be interchangeable and a client that matched them back to the wrong caller would still return a valid row for each, reporting a fast but wrong number instead of failing.
The distinct literal costs nothing on the server and does not turn this into a measurement of statement preparation: the Simple Query protocol has no server-side statement cache, so PostgreSQL parses, rewrites and plans every Query message it receives even when the text is byte-identical to the previous one. Measured, 100 concurrent calls with a constant literal land within noise of the varying one (Node -2.5% to +1.5% across repeats, Bun +0.3% - the sign flips between runs). Simple Query has no bind parameters to carry the distinct value instead, which is why this varies the text where the Extended Query counterpart varies a parameter. (concurrency=100)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 1.826 | 1.892 | 2.474 | 552.0 | 1.01x | 0.0180 | 15222.37 | 784.02 |
| pg (node-postgres) (8.23.0) | 1.841 | 1.914 | 2.478 | 547.9 | 1.00x | 0.0152 | 22198.82 | 1304.19 |
| postgres (postgres.js) (3.4.9) | 1.821 | 1.897 | 2.550 | 554.6 | 1.01x | 0.0298 | 42931.78 | 3197.87 |
Simple Query Fetch
Fetch 1000 mixed-type rows via each library's Simple Query path - the same protocol as Sequential Execution and Concurrent Execution above - on a single already-open connection, no pool. This measures row-fetch throughput without the parse/bind/describe overhead of the Extended Query protocol.
Excludes int8: pg, postgres.js and PostgreJS return it as genuinely different JS types by default (string, BigInt, number-or-BigInt). Timing that column would measure type-conversion choice, not decode speed. (rowTarget=1000)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 1.193 | 1.245 | 1.994 | 862.1 | 1.63x | 0.0279 | 17109.16 | 2087.91 |
| pg (node-postgres) (8.23.0) | 1.939 | 1.936 | 3.949 | 533.2 | 1.00x | 0.1330 | 64887.01 | 3578.95 |
| postgres (postgres.js) (3.4.9) | 1.657 | 1.616 | 4.511 | 631.8 | 1.17x | 0.1184 | 67398.96 | 6107.13 |
Extended Query
PostgreSQL's Extended Query sub-protocol: the client splits a query into separate Parse, Bind, Describe, Execute, and Sync messages instead of Simple Query's single Query message - more wire round trips per query, but it is what makes bind parameters, typed result columns, and a statement the server plans once and can re-execute possible at all (none of that exists in Simple Query). In postgrejs, Connection.query(sql) always goes through this path, and Connection.prepare(sql) additionally gives back a reusable PreparedStatement handle instead of re-sending Parse on every call. The scenarios here mirror the Simple Query group's own Sequential/Concurrent pair - a single parameterized call one at a time, then many fired concurrently over one connection - plus decoding many mixed-type rows through query() (the row count itself a bind parameter, large enough that decode work dominates the measurement) on both the text and binary wire formats, and the cost this protocol is meant to amortize away: reusing one prepared statement across many executions, sequentially and then concurrently.
Sequential Execution
The Extended Query counterpart to the Simple Query group's Sequential Execution above: one already-open connection, one call at a time, each awaited before the next starts.
Instead of a literal, it selects an int4 value bound as a real query
parameter (select $1::int4), so every library genuinely goes through
Parse/Bind/Describe/Execute/Sync rather than a single Query message.
Unlike Prepared Statement Reuse below, there is no reused or cached server-side statement here, so this isolates the one-shot per-call cost Extended Query pays on top of the Simple Query baseline. Compare it against Concurrent Execution below to see what overlapping calls buys each library here too.
The cast is int4, not a narrower integer type, on purpose. Libraries
differ in whether they declare parameter types at all: PostgreJS names an
OID for every parameter in Parse (int4 for a JS number), while pg and
postgres.js send none and let the server infer each one from context. With
a narrower target - $1::int2 - that difference stops being free: the
server has to wrap PostgreJS's int4 parameter in a runtime cast that the
others never pay for, and this scenario ends up measuring type-declaration
policy rather than Extended Query speed. Measured with a counterbalanced
A/B/B/A run (each library taking both positions in the pair, so ordering
bias cancels - it is worth ~1.4 points here on its own): against pg,
$1::int2 put PostgreJS 4.3% behind on average, $1::int4 0.5%, which
is inside this measurement's noise. Keep the parameter's declared type and
the cast's target the same.
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 0.186 | 0.188 | 0.274 | 5439.6 | 1.13x | 0.0006 | 6193.89 | 858.90 |
| pg (node-postgres) (8.23.0) | 0.210 | 0.208 | 0.344 | 4922.3 | 1.00x | 0.0009 | 15523.37 | 938.97 |
| postgres (postgres.js) (3.4.9) | 0.183 | 0.184 | 0.320 | 5559.1 | 1.14x | 0.0009 | 14612.50 | 691.25 |
Concurrent Execution
The concurrent counterpart to Sequential Execution above, same shape as the Simple Query group's Concurrent Execution.
Fire 50 genuine Extended Query
calls (select $1::int4, a real bind parameter, not a reused/cached
statement) on the SAME already-open connection without awaiting each one
individually, then await them all via Promise.all(). PostgreJS pipelines
these at the wire level, so results never cross-talk even though the
caller never awaited between calls.
Each call binds a distinct value and checks the result against it, so this scenario verifies correctness too - do the other libraries' single connections queue/pipeline Extended Query calls correctly? - not just timing.
The cast is int4, not a narrower integer type, on purpose. Libraries
differ in whether they declare parameter types at all: PostgreJS names an
OID for every parameter in Parse (int4 for a JS number), while pg and
postgres.js send none and let the server infer each one from context. With
a narrower target - $1::int2 - that difference stops being free: the
server has to wrap PostgreJS's int4 parameter in a runtime cast that the
others never pay for, and this scenario ends up measuring type-declaration
policy rather than Extended Query speed. Measured with a counterbalanced
A/B/B/A run (each library taking both positions in the pair, so ordering
bias cancels - it is worth ~1.4 points here on its own): against pg,
$1::int2 put PostgreJS 4.3% behind on average, $1::int4 0.5%, which
is inside this measurement's noise. Keep the parameter's declared type and
the cast's target the same. (concurrency=50)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 0.526 | 0.548 | 0.861 | 1935.0 | 2.12x | 0.0086 | 33190.58 | 1344.26 |
| pg (node-postgres) (8.23.0) | 1.117 | 1.170 | 1.511 | 903.4 | 1.00x | 0.0086 | 22097.13 | 2167.19 |
| postgres (postgres.js) (3.4.9) | 0.462 | 0.479 | 0.869 | 2210.2 | 2.42x | 0.0088 | 48334.81 | 3921.35 |
Mixed-Type Decode (Text Protocol)
Fetch 1000 mixed-type rows (int2/int4/ float4/float8/varchar/json/jsonb/timestamp/timestamptz/bytea) via each library's Extended Query path - PostgreJS's query(), a one-shot parameterized call, not a reused prepared statement - and decode them to JS values. The row count is itself a real bind parameter ($1), not a literal, and large enough that column-decode work dominates the measurement rather than per-call round-trip overhead.
This is the Extended Query counterpart to Simple Query Fetch above: the raw decode cost this protocol carries per call, before Prepared Statement Reuse below measures what reusing the parsed plan saves.
Excludes int8: pg, postgres.js and PostgreJS return it as genuinely different JS types by default (string, BigInt, number-or-BigInt). Timing that column would measure type-conversion choice, not decode speed.
Forces PostgreJS onto the text protocol explicitly. Its Extended Query default is binary, per-column, unlike pg and postgres.js, which are always text here - pg's binary mode is opt-in and never requested, and postgres.js has no binary protocol support at all. Without that, this scenario would compare binary decode against text decode, not decode speed. (rowTarget=1000)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 1.528 | 1.625 | 2.249 | 667.4 | 1.30x | 0.0312 | 10984.12 | 1572.43 |
| pg (node-postgres) (8.23.0) | 1.984 | 1.989 | 4.173 | 519.7 | 1.00x | 0.1300 | 64508.33 | 8816.76 |
| postgres (postgres.js) (3.4.9) | 1.636 | 1.590 | 4.186 | 638.7 | 1.21x | 0.1155 | 67528.59 | 6140.42 |
Mixed-Type Decode (Binary Protocol)
The same fetch as Mixed-Type Decode (Text Protocol) above - same
1000 rows, same columns, same bind-parameter
row count - but requesting binary result format instead of text. That is
PostgreJS's own Extended Query default (DEFAULT_COLUMN_FORMAT), so this
measures its binary decode path on its own terms rather than forcing it
onto text.
postgres.js has no binary protocol support at all: its Bind message
hardcodes text format codes for every column, with no option to request
binary (verified in its own source). It isn't benchmarked here.
pg's binary parser table (pg-types) is missing exactly the column types
this scenario decodes - varchar/json/jsonb/bytea are unregistered
for binary, only a handful of numeric/date/bool types are. Requesting
binary from pg would return those columns unparsed or corrupted rather
than a comparable value, so it's excluded rather than reported as a
misleading number.
Bun's SQL client already uses binary for several of these columns by
default - int4, float4, float8, timestamp, timestamptz, and bytea, verified
by capturing its actual Bind message over a logging TCP proxy - but int2,
int8, varchar, json, and jsonb go out as text regardless, a fixed per-type
choice with no exposed option (in the SQL constructor, .unsafe(), or the
tagged-template call) to override it either way. Since it can't be forced
into PostgreJS's "request binary for every column" shape, its result here
would be neither this scenario nor a fair text-protocol one - it isn't
benchmarked here for that reason.
Only PostgreJS's own result is shown. (rowTarget=1000)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 1.349 | 1.341 | 2.034 | 753.4 | 1.00x | 0.0284 | 11225.15 | 1398.74 |
| pg (node-postgres) | Not Fully Supported | — | — | — | — | — | — | — |
| postgres (postgres.js) | Not Supported | — | — | — | — | — | — | — |
| Bun.sql | Not Controllable | — | — | — | — | — | — | — |
Large Blob Fetch
Fetch 10 rows of a 1MB bytea value each (10MB total) via each library's Extended Query path, with the row count itself a real bind parameter, not a literal. The measurement is dominated by wire-transfer and decode time for a few large values, instead of per-row/per-column overhead across many small ones - the counterpart to Mixed-Type Decode above, which is many small values.
Unlike that scenario, no protocol format is forced onto anyone here: PostgreJS is left on its own Extended Query default (binary), and pg/postgres.js get whatever their own default is.
postgres.js has no binary protocol support at all (verified elsewhere in
this report), so it always fetches as text - hex-encoded on the wire,
decoded client-side. pg's binary parser table (pg-types) has no entry
for bytea either (verified live: requesting binary format for a bytea
column returns a corrupted value, not a Buffer) - undocumented and unsafe
to rely on, so pg is left on its own text default too, same as
postgres.js.
Only PostgreJS ends up genuinely exercising a binary fetch; the other two
show their real, best-available path rather than a forced or broken one -
and pay for it. bytea's text format is \x-prefixed hex, literally 2x the
wire bytes of binary's raw bytes, so pg and postgres.js transfer twice
what PostgreJS does here. (sizeBytes=1048576, rowCount=10)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) | Net in (KB/op) | Net out (KB/op) |
|---|---|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 30.736 | 31.373 | 34.398 | 32.6 | 2.03x | 0.7043 | 33656.07 | 9596.21 | 12412.27 | 0.06 |
| pg (node-postgres) (8.23.0) | 61.724 | 62.832 | 63.537 | 16.2 | 1.01x | 0.6337 | 89273.79 | 19806.08 | 25600.23 | 0.13 |
| postgres (postgres.js) (3.4.9) | 62.481 | 63.351 | 73.124 | 16.1 | 1.00x | 0.7253 | 84513.76 | 28108.53 | 25600.19 | 0.06 |
Large Array Fetch
Fetch 10 rows of an int4[] with 50000 elements each, via each library's Extended Query path, with the row count itself a real bind parameter, not a literal. Elements alternate between just below int4's ceiling and just above its floor, so every value is full-width and roughly half are negative. Full-width values are what show binary format's real wire advantage: binary spends a fixed 8 bytes per int4 element, while text spends one byte per digit.
This is the array counterpart to Large Blob Fetch above (one large scalar value) and Mixed-Type Decode (many small values): here it is many elements within a single column value, repeated across rows. Element count, not byte size, is what drives cost for an array, unlike a blob - see this file's own comments for the measurement that showed why - so this is sized for a clear decode-time gap without ballooning each iteration to whole seconds.
As with Large Blob Fetch, no protocol format is forced onto anyone: PostgreJS is left on its own Extended Query default (binary).
pg's binary array decode (pg-types) is registered-but-buggy rather than
simply unsupported. It does have a registered binary parser for _int4
(unlike bytea), but that parser reads every element as an unsigned bit
pattern, with no two's-complement handling for negative values. Verified
live: requesting binary format for an int4[] containing negative numbers
returns wrong values from the first negative element onward, and desyncs
the element count entirely on a larger array - a 1500-element array came
back as 1519 elements, values wrong.
So pg is left on its own text default here too, same as postgres.js (no binary protocol support at all, verified elsewhere in this report). A case where a library merely having a registered binary parser is not the same as that parser being safe to use. (elementCount=50000, rowCount=10)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) | Net in (KB/op) | Net out (KB/op) |
|---|---|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 17.550 | 18.418 | 20.698 | 57.3 | 5.46x | 0.5587 | 32029.03 | 15054.36 | 4660.47 | 0.05 |
| pg (node-postgres) (8.23.0) | 95.902 | 97.673 | 103.328 | 10.4 | 1.00x | 2.3982 | 114268.14 | 3341.47 | 7019.26 | 0.13 |
| postgres (postgres.js) (3.4.9) | 36.280 | 37.515 | 40.507 | 27.6 | 2.64x | 1.1626 | 133194.40 | 22651.11 | 6818.67 | 0.06 |
Prepared Statement Reuse (Sequential)
Prepare once and execute 50 times, one at a time, each awaited before the next starts. Each library uses its own prepared-statement mechanism: postgres.js auto-prepares, pg uses a named statement, PostgreJS uses explicit prepare()/execute()/close().
Compare it against the Concurrent variant below to see what overlapping executions of the same reused statement buys each library.
Excludes int8: pg, postgres.js and PostgreJS return it as genuinely different JS types by default (string, BigInt, number-or-BigInt), so timing it would measure type-conversion choice, not reuse cost. (iterations=50)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 9.733 | 9.817 | 11.156 | 102.8 | 1.02x | 0.0232 | 4967.07 | 1195.40 |
| pg (node-postgres) (8.23.0) | 9.939 | 10.034 | 11.851 | 100.8 | 1.00x | 0.0543 | 30246.11 | 2603.20 |
| postgres (postgres.js) (3.4.9) | 9.836 | 9.930 | 11.340 | 101.8 | 1.01x | 0.0405 | 20985.62 | 1347.56 |
Prepared Statement Reuse (Concurrent)
The concurrent counterpart to Sequential above: prepare once, then fire 50 executions of that same reused statement on the SAME already-open connection without awaiting each one individually, then await them all via Promise.all().
Each library uses its own prepared-statement mechanism: postgres.js auto-prepares, pg uses a named statement, PostgreJS uses explicit prepare()/execute()/close().
Excludes int8: pg, postgres.js and PostgreJS return it as genuinely different JS types by default (string, BigInt, number-or-BigInt), so timing it would measure type-conversion choice, not reuse cost. (concurrency=50)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 0.958 | 1.002 | 1.350 | 1056.4 | 1.06x | 0.0088 | 15371.80 | 1163.87 |
| pg (node-postgres) (8.23.0) | 1.017 | 1.067 | 1.527 | 996.6 | 1.00x | 0.0086 | 30860.59 | 2670.10 |
| postgres (postgres.js) (3.4.9) | 0.952 | 0.985 | 1.592 | 1069.3 | 1.07x | 0.0120 | 57708.37 | 5344.61 |
Unit of Work
Several different statements run as one unit, the shape a single request usually has - a few writes, a few reads, none of them repeating. Every library sends them without waiting between replies, which all three can do; what separates them is whether each statement still costs its own Sync, and with it a round of the server's implicit-transaction bookkeeping. Distinct from the Concurrent Execution scenarios above, where the same query is fired many times and a parsed plan can be shared.
Unit of Work
Runs 20 different statements - ten writes, five reads, then five more writes - as one unit, the shape a single request usually has. Unlike the Concurrent Execution scenarios, which fire the same query many times, every statement here is different, so none of them can share a parsed plan with another.
Each library uses the fastest path it has for this. pg and postgres.js fire
the statements through Promise.all() without awaiting between them, which
is genuinely their best: both pipeline, so the statements travel without
waiting for each other's replies. postgres.js builds them from its tagged
template rather than sql.unsafe() - on this workload that is 3.5x faster
for it (4.4ms against 15.5ms), so the $1 form would have measured a path
its users have no reason to take. PostgreJS uses pipeline(), which goes
one step further and closes all twenty with a single Sync instead of one
each.
That last step is what the scenario is really measuring, and it is not a
configuration difference: a Sync per statement makes the server finish an
implicit transaction and answer ReadyForQuery every time, and neither other
driver can avoid it - pg sends one immediately after each Execute, and
postgres.js concatenates Execute and Sync into a single constant, so the
two cannot come apart. Compare against Concurrent Execution (Extended
Query) above to see the same libraries running the same number of calls
when the statements are identical rather than different. (statementCount=20)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 0.613 | 0.619 | 0.773 | 1648.5 | 4.33x | 0.0034 | 5548.44 | 866.70 |
| pg (node-postgres) (8.23.0) | 2.654 | 2.685 | 3.419 | 381.2 | 1.00x | 0.0123 | 16121.58 | 1773.69 |
| postgres (postgres.js) (3.4.9) | 1.999 | 2.037 | 2.540 | 502.7 | 1.33x | 0.0111 | 20235.98 | 2521.73 |
Bulk Load
COPY ... FROM STDIN, the path PostgreSQL optimises for writing many rows at once - one statement carrying a stream of rows instead of an INSERT per row or a bind per row. The two scenarios are the same 200,000 rows sent two ways: as CSV every library formats itself, and as the binary COPY format only PostgreJS can produce. Read them together - the text table is what separates the drivers, and the difference between the tables is what the format buys. Both scenarios truncate the destination inside the timed call and start from the same materialised rows, so each library pays for its own formatting rather than being handed a payload someone else built.
Bulk Load (text COPY)
Bulk-loads 200,000 rows into an empty table over
COPY ... FROM STDIN, the path PostgreSQL itself optimises for bulk
writes. Each iteration truncates the destination first, so every run loads
into the same empty table - the truncate is inside the timed call and
costs every library the same.
Column values hug each type's widest text form, the same choice the seeded tables make: binary costs a fixed number of bytes per column whatever the value is, while text costs one per character, so a payload of small numbers would understate the format difference and unusually long ones would overstate it.
That choice moves the headline enough to state outright. On these same 200,000 rows, text against binary: with these values (10-digit int4, 19-digit int8, widest float8, 40-char varchar) 2495ms against 242ms, a 10.3x gap over ~22MB of CSV; with single-digit numbers and 4-char strings instead, 497ms against 187ms, a 2.7x gap over ~8MB. Both are honest for their own data and neither is universal - binary's cost per column doesn't move between those runs, what changes is how much text the server has to parse. Place the table against your own rows rather than reading one figure as the answer.
This is the like-for-like comparison: every library formats the same CSV
payload and streams it as bytes, which is the only thing pg and
postgres.js can do (see Bulk Load (binary COPY) below). PostgreJS uses its
own copyFrom() byte stream here rather than copyFromRows(), so what
is measured is the driver's COPY transport, not the format.
pg needs pg-copy-streams for this at all - its core Query refuses
COPY IN - which is installed here so it runs its real path rather than
being marked unsupported. (rowCount=200000)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) | Net in (KB/op) | Net out (KB/op) |
|---|---|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 1498.932 | 1500.909 | 1510.310 | 0.7 | 1.00x | 25.2829 | 223063.66 | 22482.28 | 0.09 | 32387.29 |
| pg (node-postgres) (8.23.0) | 1493.588 | 1492.173 | 1501.382 | 0.7 | 1.00x | 22.0025 | 223146.52 | 22396.59 | 0.18 | 32387.36 |
| postgres (postgres.js) (3.4.9) | 1490.658 | 1491.944 | 1497.446 | 0.7 | 1.01x | 21.5756 | 246248.93 | 45536.79 | 0.18 | 32387.38 |
| Bun.sql | No COPY API | — | — | — | — | — | — | — | — | — |
Bulk Load (binary COPY)
Bulk-loads 200,000 rows into an empty table over
COPY ... FROM STDIN, the path PostgreSQL itself optimises for bulk
writes. Each iteration truncates the destination first, so every run loads
into the same empty table - the truncate is inside the timed call and
costs every library the same.
Column values hug each type's widest text form, the same choice the seeded tables make: binary costs a fixed number of bytes per column whatever the value is, while text costs one per character, so a payload of small numbers would understate the format difference and unusually long ones would overstate it.
That choice moves the headline enough to state outright. On these same 200,000 rows, text against binary: with these values (10-digit int4, 19-digit int8, widest float8, 40-char varchar) 2495ms against 242ms, a 10.3x gap over ~22MB of CSV; with single-digit numbers and 4-char strings instead, 497ms against 187ms, a 2.7x gap over ~8MB. Both are honest for their own data and neither is universal - binary's cost per column doesn't move between those runs, what changes is how much text the server has to parse. Place the table against your own rows rather than reading one figure as the answer.
The same rows as Bulk Load (text COPY) above, loaded through PostgreJS's
copyFromRows(), which encodes them into PostgreSQL's binary COPY format
instead of CSV. Read the two tables together: the difference between them
is what the format buys, while the text table alone is what separates the
drivers.
pg and postgres.js are absent because neither can produce the format.
Both can carry a binary COPY payload the caller has already encoded - so
this is not a missing transport - but producing it needs a binary encoder
per type, which neither has. For pg a third-party package,
pg-copy-streams-binary, supplies its own encoders; it is left out here
for the same reason pg-native is, being outside the driver rather than
part of it. (rowCount=200000)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) | Net in (KB/op) | Net out (KB/op) |
|---|---|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 107.718 | 107.809 | 124.426 | 9.4 | 1.00x | 1.6112 | 72473.11 | 8965.20 | 0.28 | 21327.95 |
| pg (node-postgres) | No binary COPY encoding | — | — | — | — | — | — | — | — | — |
| postgres (postgres.js) | No binary COPY encoding | — | — | — | — | — | — | — | — | — |
| Bun.sql | No COPY API | — | — | — | — | — | — | — | — | — |
Cursor Streaming
A server-side cursor (postgrejs's Connection.query(sql, { cursor: true })) fetches rows in bounded batches via repeated Extended Query Execute calls against a portal, instead of the server materializing and sending the whole result set at once. The relevant metric when a result set doesn't comfortably fit in memory, not raw single-shot throughput.
Cursor Streaming
Stream 50000 rows via a server-side cursor in batches of 500. Excludes int8: pg/postgres.js/PostgreJS return it as genuinely different JS types by default (string/BigInt/number-or-BigInt), so timing it would measure type-conversion choice, not streaming throughput.
Bun's SQL client has no cursor/streaming API at all - no .cursor(), no
.forEach(), no Symbol.asyncIterator on a query (verified against its
own type declarations and empirically). It isn't benchmarked here. (rowTarget=50000, batchSize=500)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 91.910 | 92.792 | 95.742 | 10.9 | 1.29x | 1.8271 | 11972.53 | 1903.92 |
| pg (node-postgres) (8.23.0) | 118.338 | 118.909 | 127.350 | 8.5 | 1.00x | 6.6927 | 77194.42 | 3269.00 |
| postgres (postgres.js) (3.4.9) | 113.634 | 113.929 | 118.815 | 8.8 | 1.04x | 6.3001 | 68364.83 | 4053.29 |
| Bun.sql | Not Supported | — | — | — | — | — | — | — |
Connection Pooling
The overhead each library's connection pool adds on top of the raw per-query costs measured above: running many queries concurrently through a shared pool (postgrejs's Pool.query()), and isolating the pure cost of acquiring and releasing a pooled connection from the cost of the query itself.
Pooled Simple Query
Same query as Sequential Execution/Concurrent Execution above,
run through a pool instead of a single open connection:
1000 concurrent select 1 as one
queries against a pool of max size 10,
using each library's own top-level pooled entry point. (concurrency=1000, poolSize=10)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 6.590 | 7.023 | 9.969 | 156.2 | 6.56x | 0.3796 | 77314.42 | 733.91 |
| pg (node-postgres) (8.23.0) | 43.207 | 43.841 | 53.574 | 23.3 | 1.00x | 0.5453 | 17234.39 | 1722.10 |
| postgres (postgres.js) (3.4.9) | 9.581 | 12.635 | 16.244 | 120.9 | 4.51x | 0.3972 | 88132.25 | 7171.30 |
Pooled Extended Query
The Extended Query counterpart to Pooled Simple Query above: the
same 1000 concurrent calls against a
pool of max size 10, but binding a
real query parameter (select $1::int4 as one) so every library goes
through Parse/Bind/Describe/Execute/Sync instead of a single Query
message.
Each call is a one-shot statement, not a reused prepared one, so this shows what a pool costs on top of the per-call Extended Query overhead. Compare it against this group's Pooled Simple Query to see what the extra protocol round of messages adds once connections are being shared.
Read the margin here with that one-shot constraint in mind. postgres.js's
unprepared path (sql.unsafe(query, args), the same call the
single-connection Sequential Execution scenario uses, where it comes out
ahead) does not pipeline a burst the way its prepared path does. Letting
it cache the statement instead turns this into a different measurement
entirely, which is what Prepared Statement Reuse below covers. (concurrency=1000, poolSize=10)
| Library | Mean (ms) | p75 (ms) | p99 (ms) | ops/sec | vs. slowest | GC (ms/op) | Peak Heap (KB) | Retained (KB) |
|---|---|---|---|---|---|---|---|---|
| PostgreJS (3.12.0) | 6.654 | 7.080 | 11.165 | 154.1 | 6.69x | 0.2982 | 78738.24 | 1394.73 |
| pg (node-postgres) (8.23.0) | 44.490 | 45.210 | 50.453 | 22.6 | 1.00x | 0.6130 | 18277.67 | 2031.25 |
| postgres (postgres.js) (3.4.9) | 9.582 | 12.640 | 16.179 | 126.6 | 4.64x | 0.3695 | 83374.17 | 5684.97 |
Raw data
Backing raw data for the numbers above lives in benchmark/results/node/*.json (gitignored; regenerate with npm run bench).