Order-of-magnitude larger query size with pg-adapter?

[jekh]

Question

On 6.19.0, I recently updated to use @prisma/adapter-pg, in preparation for 7.0. I immediately noticed that network traffic to Postgres went through the roof, a >10x increase in production, with a corresponding significant (~+50%) CPU increase.

Is this a known issue? Is there maybe some node-postgres setting I missed or something? This huge of a difference seems like it has to be a misconfiguration. You can clearly see the switch to driver adapters, and the switch back, with no other changes in between:

Running node 24 on Alpine, against an AWS RDS Postgres instance. I am not using native libpq with @prisma/adapter-pg -- is that recommended? The provider in both cases is provider = "prisma-client", the only difference is engine-type="client" when using the driver adapter, and of course providing the adapter to PrismaClient.

How to reproduce (optional)

No response

Expected behavior (optional)

No response

Information about Prisma Schema, Client Queries and Environment (optional)

No response

[nurul3101]

Hi @jekh!

Thank you for raising this. This is not a known issue. I have shared it with our Prisma ORM team internally to get insights on what could cause this behaviour. One possible hunch could be missing statement cache in Driver Adapters.

I'll get back to you on this.

[jekh]

I did finally get around to investigating this, since the issue is still occurring. The problem is indeed missing the prepared statement name in Driver Adapters.

Here's a repro: https://github.com/jekh/prisma-stmt-test

And a PR to fix it: #29337

The TL;DR of the fix is probably this:

With unnamed prepared statements, every query execution sends a Parse message containing the full SQL text over the wire. For queries selecting many columns from wide tables, this SQL text can be 500-1000+ bytes per query.
With named prepared statements, the full SQL is sent only once per statement name per connection (in the initial Parse message). All subsequent executions of the same statement send only a Bind+Execute message containing the short statement name (18 bytes, e.g., p_ccaf53b43fe3f238) plus parameter values — no SQL text.

It results in an 80+% reduction in SQL text over the wire, and a significant reduction in CPU.

[GitNimay]

This is worth opening as a bug or performance regression report.

A 10x increase in traffic from the app to Postgres does not sound like something that should be explained only by switching from the Rust query engine to @prisma/adapter-pg. Some increase in CPU or different pooling behavior would be plausible, but that size of network delta suggests either a query planning or protocol behavior difference that Prisma should probably look at.

A few things I would check first:

Pool configuration

With engineType = "client" and @prisma/adapter-pg, pooling is handled by pg, not Prisma’s Rust engine pool. So any previous URL options like this may no longer have the same effect:

DATABASE_URL="postgresql://user:password@host:5432/db?connection_limit=10&pool_timeout=10"

Instead, configure the pg pool explicitly:

import { Pool } from "pg";
import { PrismaPg } from "@prisma/adapter-pg";
import { PrismaClient } from "./generated/prisma/client";

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 10,
  idleTimeoutMillis: 300_000,
  connectionTimeoutMillis: 5_000,
});

const adapter = new PrismaPg(pool);
const prisma = new PrismaClient({ adapter });

If you have multiple Node processes or containers, max needs to be sized per process, not globally.

Query shape

I would also compare actual SQL emitted before and after the switch. Enable query logging in both versions and check whether the adapter version is producing more SQL statements for the same request path:

const prisma = new PrismaClient({
  adapter,
  log: ["query", "warn", "error"],
});

If the traffic increase is from more statements, that points toward a Prisma client engine or query compiler difference. If the number of statements is the same but bytes sent to Postgres are much higher, that points more toward protocol, parameter encoding, prepared statement, or driver behavior.

Native libpq

I would not assume pg-native is the intended fix here. node-postgres supports native bindings, but the pure JavaScript driver is normal and production suitable. Native bindings may change parsing behavior and add Alpine build/runtime complexity, but they should not be required to avoid a 10x network increase.

What would make this actionable

The most useful reproduction would be:

Prisma version: 6.19.0
Node version: 24
Base image: Alpine
Database: AWS RDS Postgres
Adapter: @prisma/adapter-pg
Engine type: client
pg version:
Whether PgBouncer or RDS Proxy is involved:
Pool config used with pg:

And then one representative endpoint or job with:

1. Query logs using the Rust engine
2. Query logs using engineType = "client" plus @prisma/adapter-pg
3. Number of SQL statements in each run
4. Bytes sent to Postgres in each run
5. Whether relationLoadStrategy is query or join, if relevant

My guess is that this is not simply “you forgot pg-native.” The first thing I would suspect is that the switch changed either pooling defaults or the generated SQL/query execution path. If the query count is identical but network bytes explode, that would be a strong signal for an adapter or driver level regression.

[logusivam]

This is a real, confirmed issue — not a misconfiguration on your end. The root cause has been identified and a fix PR has been submitted.

---

Root cause — missing prepared statement names in the Driver Adapter path

The problem is that @prisma/adapter-pg does not pass prepared statement names when sending queries to Postgres. This causes a fundamental difference in how the PostgreSQL wire protocol behaves:

Without the Driver Adapter (Rust query engine):
Named prepared statements are used. The full SQL text is sent once per statement name per connection (in the initial Parse message). All subsequent executions of the same statement send only a Bind + Execute message containing the short statement name (18 bytes, e.g. p_ccaf53b43fe3f238) plus parameter values — no SQL text.

With @prisma/adapter-pg (Driver Adapter path):
Every query execution sends a Parse message containing the full SQL text over the wire. For queries selecting many columns from wide tables, this SQL text can be 500–1,000+ bytes per query, on every single execution.

This directly explains both observations in your metrics:

• >10x network traffic increase: full SQL text sent every execution instead of just a short statement name
• ~50% CPU increase: Postgres re-parses and re-plans the full SQL on every execution instead of reusing a cached plan

---

Status

The original poster investigated this and confirmed the root cause — the fix is in PR #29337 against the Prisma repo. As of this writing, the fix has not yet been merged into a release. You can track PR #29337 to know when it lands.

---

What to do right now

Option 1 — Revert to the Rust query engine until the fix is released

Remove engine-type="client" and the @prisma/adapter-pg instantiation. Since you already confirmed reverting fixes the issue, this is the safest immediate action for production.

Option 2 — Stay on the Driver Adapter path but reduce impact with explicit pool configuration

If you need to stay on the adapter path, make sure you are configuring the pg Pool explicitly rather than relying on defaults. With the adapter, pooling is handled entirely by pg, not Prisma's Rust engine:

import { Pool } from 'pg';
import { PrismaPg } from '@prisma/adapter-pg';
import { PrismaClient } from './generated/prisma/client';

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 10,                          // size per process/container
  idleTimeoutMillis: 300_000,
  connectionTimeoutMillis: 5_000,
});

const adapter = new PrismaPg(pool);
const prisma = new PrismaClient({ adapter });

⚠️ This does not fix the underlying prepared statement issue — it only ensures your pool isn't misconfigured on top of it. The traffic increase will persist until PR #29337 is released.

Option 3 — Enable query logging to quantify the impact on your specific workload

const prisma = new PrismaClient({
  adapter,
  log: ['query', 'warn', 'error'],
});

Compare the number of SQL statements and the byte size of queries between the Rust engine and adapter paths to confirm the exact multiplier in your workload. If your queries are narrow (few columns, short SQL), the impact will be smaller than for wide-table queries.

---

On your question about pg-native / libpq

Using native libpq (pg-native) is not the intended fix here and not required for production use. The pure JavaScript pg driver is production-suitable. Native bindings change parsing behavior and add Alpine build complexity but would not resolve the prepared statement naming issue — that is a Prisma adapter-level problem, not a driver implementation problem. Do not pursue this as a workaround.

---

Summary

Question	Answer
Is this a known issue?	Yes — confirmed by both a Prisma maintainer and the original poster's own investigation
Root cause	@prisma/adapter-pg sends unnamed prepared statements, causing full SQL text to be sent on every query execution instead of a short cached statement name
Expected traffic reduction after fix	80%+ reduction in SQL bytes over the wire
Fix available?	PR #29337 submitted — not yet released as of this writing
Should you use pg-native?	No — unrelated to this issue
Recommended action now	Revert to Rust engine for production until PR #29337 lands in a release

Hope this helps — if it answers your question, would you mind clicking "Mark as answer" so others searching for the same thing can find it quickly?