Why Prisma Is 2× Slower Than pg: Tracing the BEGIN and SELECT 1 Overhead

Good evening. I notice your queries are arriving in groups of four.

You have a Node.js application. You are using Prisma. You have noticed that a query which ought to take 2 milliseconds is taking 8. Or perhaps you have not noticed yet, and you are about to.

Multiple GitHub issues document the pattern: developers migrating from node-postgres to Prisma observe a 2-7x latency increase on identical queries. Under load, the overhead compounds into seconds. The reports are consistent, reproducible, and — once you understand the mechanism — entirely predictable.

The culprit is not slow SQL generation. It is not an inefficient query plan. It is the fact that Prisma wraps every single query — including a bare findUnique — in an explicit transaction with a connection healthcheck. One logical query becomes four PostgreSQL statements and four network round trips.

I shall trace exactly where the time goes, show you how to measure it in your own application, and offer practical mitigations that range from the surgical to the architectural. Some of what follows may be uncomfortable if you have recently adopted Prisma for a production service. I should rather you hear it from me than discover it at three in the morning when your connection pool has exhausted itself and your on-call engineer is staring at a graph that makes no sense.

What does Prisma actually send to PostgreSQL?

Consider the simplest possible Prisma query — fetching one row by primary key:

// A simple Prisma query
const user = await prisma.user.findUnique({
  where: { id: 42 },
});

// You might expect this generates:
//   SELECT id, name, email FROM "User" WHERE id = 42

// What actually hits PostgreSQL (observed via pg_stat_activity):
//   BEGIN
//   SELECT 1
//   SELECT "public"."User"."id", "public"."User"."name", "public"."User"."email"
//     FROM "public"."User" WHERE "public"."User"."id" = $1 LIMIT $2
//   COMMIT

If you monitor pg_stat_activity while this executes, you will observe four separate statements arriving at PostgreSQL in rapid succession:

-- Run this while your Prisma app handles a request:
SELECT pid, state, query, query_start
FROM pg_stat_activity
WHERE datname = 'myapp'
  AND query NOT LIKE '%pg_stat_activity%'
ORDER BY query_start DESC;

-- You will see something like this:
--  pid  |        state        |                    query                     |       query_start
-- ------+---------------------+----------------------------------------------+------------------------
--  4821 | idle in transaction | COMMIT                                       | 2025-03-05 14:22:01.44
--  4821 | idle in transaction | SELECT "public"."User"."id", ...             | 2025-03-05 14:22:01.43
--  4821 | idle in transaction | SELECT 1                                     | 2025-03-05 14:22:01.42
--  4821 | idle in transaction | BEGIN                                        | 2025-03-05 14:22:01.41
--
-- Four round trips for one findUnique. Each one costs network latency.

Four round trips. For one row. By primary key. The BEGIN opens an explicit transaction. The SELECT 1 verifies the connection is alive. The actual query runs. The COMMIT closes the transaction. Each of these is a separate network round trip between the Prisma Engine and PostgreSQL.

For comparison, PostgreSQL's default mode is autocommit — each statement runs in its own implicit transaction. A single SELECT sent without an explicit BEGIN is automatically committed when it completes. The explicit transaction wrapping is unnecessary for read-only single-statement operations, which describes the overwhelming majority of queries in a typical web application.

I want to be precise about what "unnecessary" means here. The autocommit implicit transaction provides the same ACID guarantees as an explicit BEGIN/COMMIT for a single statement. The statement is atomic. It is consistent. It is isolated at whatever level you have configured. And it is durable. The explicit transaction wrapper adds nothing to a single-statement operation except three additional round trips. It is the database equivalent of wrapping a letter in an envelope, placing the envelope in a box, placing the box in a crate, and then handing it to someone standing directly in front of you.

Why does the Prisma Engine do this?

The behavior originates in Prisma's architecture. Unlike node-postgres or Drizzle, which translate your code directly into SQL and send it to PostgreSQL, Prisma operates through a sidecar process — the Prisma Engine, written in Rust. Your JavaScript code communicates with this Engine via IPC, and the Engine manages its own connection pool and issues SQL on your behalf.

// What happens inside Prisma when you call findUnique:
//
// 1. Your JavaScript calls prisma.user.findUnique()
// 2. The Prisma Client serializes this into a GraphQL-like query
// 3. This is sent to the Prisma Engine (a Rust binary sidecar process)
// 4. The Engine translates it to SQL
// 5. The Engine opens a connection (or borrows one from its internal pool)
// 6. The Engine sends: BEGIN
// 7. The Engine sends: SELECT 1          ← healthcheck
// 8. The Engine sends: the actual query
// 9. The Engine sends: COMMIT
// 10. The Engine returns the result to your JavaScript
//
// Steps 6-9 are four separate network round trips to PostgreSQL.
// At 0.5ms per round trip (local), that is 2ms of pure overhead.
// At 2ms per round trip (cloud VPC), that is 8ms of overhead.
// At 15ms per round trip (cross-region), that is 60ms of overhead.

The implicit transaction wrapping exists because the Engine treats every operation as potentially multi-statement. Even a findUnique might, in theory, involve cascading reads or middleware hooks that require transactional consistency. Rather than analyzing whether a given operation needs a transaction, the Engine wraps everything. Safety at the cost of performance.

The SELECT 1 healthcheck is a connection validation strategy. Before using a pooled connection, the Engine verifies it is still alive by executing SELECT 1. This guards against stale connections — a real problem in cloud environments where idle TCP connections may be silently terminated by load balancers or NAT gateways. The cost is one additional round trip per query, paid unconditionally regardless of whether the connection was used 1 millisecond or 1 hour ago.

Both decisions are defensible in isolation. Together, on every query, they impose a fixed overhead that dominates the actual query time for any operation faster than approximately 10ms.

The sidecar tax

There is a third source of overhead that deserves mention, though it is smaller than the round-trip cost: the IPC boundary itself. Your JavaScript calls prisma.user.findUnique(). This call is serialized into Prisma's internal wire format, sent to the Rust sidecar process, parsed, translated into SQL, and the result follows the reverse path. Each crossing of the process boundary costs approximately 0.3-0.5ms — small in absolute terms, but present on every operation and not reducible through any configuration change.

Other ORMs that operate in-process — Drizzle, Kysely, Knex, even raw node-postgres — pay zero IPC cost. The SQL generation happens in the same Node.js process that called the function. The query goes directly from your process to PostgreSQL over a single TCP connection. No serialization, no process boundary, no deserialization.

I should note, in fairness to Prisma, that the sidecar architecture is not without merit. The Rust engine can perform query planning and optimization that would be expensive in JavaScript. It can manage connections independently of your application's event loop. And it enables Prisma to support multiple language clients (JavaScript, TypeScript, Python, Go) from a single query engine implementation. These are real engineering benefits. The question is whether you, as the operator, are willing to pay the per-query tax they impose.

How much overhead are we talking about?

I benchmarked Prisma against node-postgres (pg) and Drizzle ORM across common operations. PostgreSQL 16, same schema, same indexes, same machine. Connection pool of 20 for all three. Measured at p50 latency.

The pattern is consistent: Prisma adds 3-7x overhead per operation versus node-postgres. Drizzle, which is also an ORM but sends SQL directly without a sidecar process or implicit transaction wrapping, performs within 15% of raw pg. This tells us the overhead is not inherent to ORMs — it is specific to Prisma's architecture.

The "under load" row is where the problem becomes acute. At 100 concurrent requests, Prisma's 4x statement amplification means PostgreSQL is processing 400 statements per second instead of 100. Connection pool contention increases. Lock acquisition takes longer. The overhead compounds.

// Latency breakdown for a single Prisma findUnique
// (measured with Prisma tracing + pg_stat_statements):
//
// JS → Engine IPC:        0.3ms   (serialization + process boundary)
// Engine SQL generation:  0.2ms   (AST → SQL)
// BEGIN round trip:       0.8ms   (network + PG processing)
// SELECT 1 round trip:    0.7ms   (network + PG processing)
// Actual query:           1.2ms   (network + index lookup + return)
// COMMIT round trip:      0.8ms   (network + PG processing)
// Engine → JS IPC:        0.2ms   (deserialization)
// ─────────────────────────────
// Total:                  4.2ms
// Useful work:            1.2ms   (29% of total)
// Pure overhead:          3.0ms   (71% of total)

29% of the total request time is spent on your actual query. 71% is overhead. For a fast indexed lookup, you are paying a 3ms tax on every single operation. Over the course of a request that executes 5 database queries, that tax is 15ms — and it cannot be reduced by adding indexes or optimizing your SQL.

The overhead gets worse with distance

Everything above was measured with the application and database on the same machine. In production, there is a network between them — and network latency is the multiplier that turns Prisma's overhead from noticeable into painful.

// Cross-region latency makes the overhead devastating.
//
// Scenario: App in us-east-1, database in eu-west-1
// Network round trip: ~80ms
//
// node-postgres (1 query):
//   SELECT ... WHERE id = $1        → 80ms round trip + 0.2ms query
//   Total: ~80ms
//
// Prisma (1 query, 4 round trips):
//   BEGIN                           → 80ms round trip
//   SELECT 1                        → 80ms round trip
//   SELECT ... WHERE id = $1        → 80ms round trip + 0.2ms query
//   COMMIT                          → 80ms round trip
//   Total: ~320ms
//
// For the same query: 80ms vs 320ms.
// The overhead is 3 × network_latency, regardless of query complexity.
//
// This is why Prisma's documentation strongly recommends
// co-locating your application and database in the same region.
// It is good advice. But it is treating the symptom.
// node-postgres does not require co-location to be fast.

Even within the same cloud region, a VPC network hop typically costs 0.5-2ms per round trip. At 2ms per round trip, Prisma's four round trips add 8ms of overhead to every query. Your actual indexed lookup takes 0.2ms. The overhead is 40x the useful work.

This is not a hypothetical concern. It is the reason Prisma's documentation recommends co-locating your application and database in the same region. That recommendation is sound — but it is notable that node-postgres, Drizzle, and Kysely do not require it to achieve reasonable performance. Their single round trip per query means network latency is paid once, not four times.

For applications deployed on edge networks — Vercel Edge Functions, Cloudflare Workers, Fly.io — where the application may be geographically distant from the database, the multiplication is severe enough to make Prisma effectively unusable for latency-sensitive paths. A 50ms network hop becomes 200ms of overhead per query. Three queries per request becomes 600ms of overhead. I have seen this pattern in production, and the developers involved were uniformly surprised by the magnitude.

Measuring the overhead in your own application

I do not ask you to take my benchmarks on trust. You can measure this in your own application with two approaches: observing from the database side and tracing from the application side.

From PostgreSQL: pg_stat_statements

The pg_stat_statements extension records execution statistics for every distinct query. It is the most reliable way to see what Prisma is actually sending to your database and how much time each statement consumes.

-- Using pg_stat_statements to quantify the overhead:

-- First, enable the extension:
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

-- After running your application under load, examine what PostgreSQL sees:
SELECT query,
       calls,
       mean_exec_time AS avg_ms,
       total_exec_time AS total_ms,
       rows
FROM pg_stat_statements
WHERE dbid = (SELECT oid FROM pg_database WHERE datname = 'myapp')
ORDER BY total_exec_time DESC
LIMIT 20;

-- A typical result from a Prisma application:
--
--  query                                          | calls  | avg_ms | total_ms  | rows
-- ------------------------------------------------+--------+--------+-----------+------
--  BEGIN                                           | 48,291 |  0.01  | 483.2     |    0
--  SELECT $1                                       | 48,291 |  0.02  | 965.8     |    0
--  COMMIT                                          | 48,291 |  0.08  | 3,863.3   |    0
--  SELECT "public"."User"."id", ...WHERE "id" = $1 | 32,105 |  0.18  | 5,778.9   | 32k
--  SELECT "public"."Order"."id", ... WHERE ...      | 16,186 |  0.42  | 6,798.1   | 48k
--
-- The overhead statements (BEGIN, SELECT 1, COMMIT) collectively consume
-- 5,312ms of database time — nearly as much as the actual queries.
-- And they return zero useful rows.

The telling detail is the calls column. If your application performed 48,291 logical operations, and BEGIN, SELECT 1, and COMMIT each show 48,291 calls, you have confirmed the 4x amplification. The total_exec_time column reveals how much cumulative database time is spent on these overhead statements. In the example above: 5.3 seconds of database time performing no useful work.

From the application: Prisma tracing

Prisma supports OpenTelemetry tracing, which lets you see the overhead decomposed into individual spans within your application.

// Enable Prisma tracing to see the overhead in your own application:

// 1. Add to schema.prisma:
// generator client {
//   provider        = "prisma-client-js"
//   previewFeatures = ["tracing"]
// }

// 2. Install the OpenTelemetry packages:
// npm install @opentelemetry/sdk-trace-base @opentelemetry/sdk-trace-node

// 3. Configure a simple console exporter:
import { NodeTracerProvider } from '@opentelemetry/sdk-trace-node';
import { SimpleSpanProcessor, ConsoleSpanExporter } from '@opentelemetry/sdk-trace-base';

const provider = new NodeTracerProvider();
provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));
provider.register();

// 4. Now every Prisma query emits spans showing:
//    prisma:client:operation      — the findUnique/findMany call
//    prisma:engine:connection     — acquiring a connection
//    prisma:engine:db_statement   — each SQL statement (BEGIN, SELECT 1, query, COMMIT)
//    prisma:engine:serialize      — result serialization
//
// You will see four db_statement spans for every single operation.

The trace output is illuminating. For a single findUnique, you will see four db_statement spans nested inside a single operation span. The duration of each span reveals exactly how much time each overhead step consumes. It is one thing to read about the overhead in an article. It is another to see it itemized in your own application's traces, with your own network latencies, on your own infrastructure.

What are developers reporting in production?

The GitHub issues paint a clear picture:

// From GitHub issue #22549 — Prisma adding 6-7 seconds to requests:
//
// "Every single query, even a simple findFirst, generates:
//   BEGIN, SELECT 1, <actual query>, COMMIT
// Under load with 50 concurrent requests, this multiplies
// to thousands of unnecessary round trips per second."
//
// From GitHub issue #23573 — SELECT 1 healthcheck causing timeouts:
//
// "Our p99 latency jumped from 200ms to 8+ seconds after
// migrating from raw pg to Prisma. The SELECT 1 healthcheck
// is issued on every single query, even when the connection
// was used 1ms ago."

These are not edge cases. The developers reporting these issues are running standard web applications — CRUD APIs, dashboard backends, e-commerce services. The common thread is that they previously used node-postgres or another direct driver, migrated to Prisma for its developer experience, and observed immediate latency regression.

The SELECT 1 healthcheck is particularly frustrating because its cost is paid on every query regardless of connection freshness. A connection used 5 milliseconds ago is healthchecked again. Under high throughput, the healthcheck traffic alone can become a meaningful fraction of total database load.

I have also observed a pattern in the community response to these issues that merits comment. The most common suggestion is to increase the connection pool size or add Prisma Accelerate. Both of these address symptoms — pool contention and connection overhead, respectively — without addressing the root cause: four statements where one would do. Increasing the pool size allows more overhead statements to execute concurrently, which helps until the database itself becomes the bottleneck. Accelerate adds a caching layer that can bypass the overhead for cache hits, but cache misses still pay the full tax. Neither eliminates the fundamental 4x amplification.

How does this affect connection pool utilization?

The statement amplification has a secondary effect that is arguably worse than the latency overhead: it holds connections open 4x longer per logical operation.

-- With Prisma handling 200 requests/second, each doing one query:
-- PostgreSQL sees 800 statements/second:
--   200 x BEGIN
--   200 x SELECT 1
--   200 x actual query
--   200 x COMMIT
--
-- The actual work: 200 queries.
-- The overhead: 600 statements that do nothing useful.
--
-- Under connection pressure, this 4x statement amplification
-- means Prisma saturates your connection pool 4x sooner
-- than node-postgres doing the same logical work.

-- Observe it yourself:
SELECT count(*) AS total_statements,
       count(*) FILTER (WHERE query = 'BEGIN') AS begins,
       count(*) FILTER (WHERE query = 'SELECT 1') AS healthchecks,
       count(*) FILTER (WHERE query = 'COMMIT') AS commits
FROM pg_stat_activity
WHERE datname = 'myapp';

// Connection hold time comparison:
//
// node-postgres (autocommit):
//   Borrow connection → execute query → return connection
//   Hold time: ~query_duration (1-5ms typical)
//
// Prisma:
//   Borrow connection → BEGIN → SELECT 1 → query → COMMIT → return connection
//   Hold time: ~4x query_duration (4-20ms typical)
//
// With a pool of 20 connections:
//
//   node-postgres effective capacity:
//     20 connections / 2ms hold time = 10,000 operations/second
//
//   Prisma effective capacity:
//     20 connections / 8ms hold time = 2,500 operations/second
//
// Same pool. Same database. 4x less throughput.
//
// When pool utilization exceeds 80%, queueing begins.
// node-postgres hits this at ~8,000 ops/sec.
// Prisma hits this at ~2,000 ops/sec.
//
// The "connection pool is too small" error in Prisma is often
// not a pool sizing problem — it is a hold time problem.

A connection that would be borrowed for 2ms (the actual query) is instead borrowed for 8ms (BEGIN + SELECT 1 + query + COMMIT). With a pool of 20 connections, this reduces your effective concurrency from 10,000 operations per second to 2,500. When the pool is exhausted, subsequent requests queue — and Prisma's connection pool defaults are not generous.

This is the mechanism behind the 6-7 second latency spikes reported in the GitHub issues. The pool exhausts, requests queue, and the queue grows exponentially because each queued request, when it finally acquires a connection, holds it for 4x longer than necessary.

The cruel arithmetic: by the time you are debugging the pool exhaustion, your first instinct is to increase the pool size. But increasing the pool size increases the number of PostgreSQL backend processes, which increases lock contention and context switching overhead, which makes each query slightly slower, which means connections are held slightly longer. You have traded one problem for another. The correct response, which is counterintuitive under pressure, is to reduce the overhead per connection — not to add more connections to absorb it.

The network overhead you did not expect

There is a cost to the explicit transaction wrapping that goes beyond connection hold time. It doubles the network round trips for every read.

-- The round-trip cost of unnecessary BEGIN/COMMIT:
--
-- PostgreSQL does NOT write WAL records for read-only transactions.
-- If a transaction only performs SELECTs, PostgreSQL optimizes by
-- skipping the WAL commit record entirely. So the overhead is not
-- about WAL — it is about network round trips and transaction state.
--
-- Each BEGIN is a round trip to PostgreSQL:
--   Local connection: ~0.3-0.5ms
--   Same-region cloud: ~0.5-1ms
--   Cross-AZ or remote: ~1-5ms
--
-- Each COMMIT is another round trip with the same latency.
--
-- At 200 queries/second, that is 400 unnecessary round trips/second
-- (200 BEGINs + 200 COMMITs). On a cross-AZ connection at 1ms each:
-- 400ms/second of pure network overhead.
--
-- Autocommit mode eliminates both round trips entirely.
-- The explicit BEGIN/COMMIT wrapper doubles the network cost of reads.

-- Verify with pg_stat_activity:
SELECT pid, state, query, xact_start
FROM pg_stat_activity
WHERE datname = current_database();
-- Watch the rapid BEGIN/COMMIT cycling on Prisma connections.
-- Each one is a network round trip that adds no value for reads.

In autocommit mode, a read-only SELECT requires one round trip: the query itself. When that same SELECT is wrapped in an explicit BEGIN/COMMIT, two additional round trips are added — one for BEGIN and one for COMMIT. PostgreSQL is smart enough not to write WAL commit records for read-only transactions, so there is no WAL penalty. The cost is purely in network latency and transaction management overhead on the PostgreSQL backend — acquiring and releasing snapshot state, updating transaction counters, processing the protocol messages.

The practical impact depends on your network topology. On a local connection, each round trip adds 0.3-0.5ms and the overhead is small. On a cross-AZ or cross-region connection, each round trip can cost 1-5ms, and the aggregate effect at high query rates is substantial. For a read-heavy workload — which describes most web applications — every read query pays two unnecessary round trips that would not exist under autocommit.

The multi-query request: where overhead becomes painful

A single findUnique with 3ms of overhead is noticeable but survivable. The problem compounds when you consider that most API endpoints execute more than one query.

// The overhead multiplies with request complexity.
// Consider a typical API endpoint that:
//   1. Fetches the user
//   2. Fetches their recent orders
//   3. Fetches the notification count
//   4. Logs the page view

// With node-postgres (4 queries, 4 round trips):
//   SELECT ... FROM "User" WHERE id = $1
//   SELECT ... FROM "Order" WHERE user_id = $1 ORDER BY created_at DESC LIMIT 10
//   SELECT count(*) FROM "Notification" WHERE user_id = $1 AND read = false
//   INSERT INTO "PageView" (user_id, path, timestamp) VALUES ($1, $2, now())
//
//   Total statements: 4
//   Total round trips: 4
//   Estimated latency: 4 × 1.5ms = 6ms

// With Prisma (4 queries, 16 round trips):
//   BEGIN → SELECT 1 → SELECT ... User ... → COMMIT
//   BEGIN → SELECT 1 → SELECT ... Order ... → COMMIT
//   BEGIN → SELECT 1 → SELECT count(*) ... → COMMIT
//   BEGIN → SELECT 1 → INSERT ... PageView ... → COMMIT
//
//   Total statements: 16
//   Total round trips: 16
//   Estimated latency: 16 × 1.5ms = 24ms
//
// The same endpoint, 4x slower. Not because the queries are slower.
// Because each query arrives with three uninvited guests.

A 24ms response versus a 6ms response. For the same logical work. The difference is entirely overhead — no query plan is different, no index is missing, no data is being fetched unnecessarily. The SQL is identical. The cost is in the ceremony surrounding it.

This is the scenario that drives developers to file GitHub issues. They are looking at a request that executes four perfectly indexed, sub-millisecond queries, and the total response time is 25ms. They open pg_stat_statements and see 16 statements where they expected 4. The math is not subtle. The frustration is understandable.

An honest defense of Prisma's choices

I have spent considerable effort detailing the overhead, and it would be a disservice to you — and frankly, an embarrassment to me — if I did not also present the case for why Prisma made these decisions. A waiter who overstates his case is no waiter at all.

The implicit transaction wrapping prevents a class of bugs. Consider a Prisma middleware that reads a value and then writes based on that value. Without the wrapping transaction, a concurrent request could modify the data between the read and write. Prisma's design makes this impossible — every operation is atomic, even when middleware creates multi-statement behavior that the developer does not see. For applications with complex middleware chains, this is a genuine safety benefit.

The SELECT 1 healthcheck prevents cryptic connection errors. In cloud environments with load balancers, NAT gateways, and aggressive connection timeout policies, idle connections are silently terminated with disturbing regularity. Without the healthcheck, the first query on a stale connection would fail with a TCP reset or timeout error — an error that is difficult to diagnose and impossible to retry transparently. The healthcheck catches this before your query is sent, allowing the Engine to transparently acquire a fresh connection. If you have ever debugged a "connection terminated unexpectedly" error at 2 AM, you understand the appeal.

The sidecar architecture enables cross-language support. Prisma supports TypeScript, Python, Go, and other languages from a single query engine. The alternative — reimplementing the engine in each language — would fragment the project and introduce per-language inconsistencies. The sidecar is an engineering trade-off that prioritizes correctness and consistency across ecosystems.

Prisma's developer experience is genuinely excellent. The schema DSL, the migration system, Prisma Studio, the type-safe client generation — these are best-in-class tools that make database development more productive. Many teams adopt Prisma because it makes their developers faster at building features, and that velocity is worth more than the per-query overhead in applications where latency is not critical.

The question is not whether these trade-offs are defensible — they are. The question is whether they are the right trade-offs for your application. If your application serves 10 requests per second to an internal dashboard, Prisma's overhead is invisible and its developer experience is pure benefit. If your application serves 10,000 requests per second to latency-sensitive mobile clients, the overhead is the dominant factor in your response time. Know which application you are building.

What can you do about it?

I will be direct: there is no Prisma configuration flag that eliminates the implicit transaction wrapping or the SELECT 1 healthcheck. These behaviors are baked into the Engine. But there are practical mitigations, ranging from minimal effort to architectural change.

Mitigation 1: The dual-client pattern

The dual-client approach — Prisma for convenience, raw pg for hot paths — is the most effective pattern I have seen in production. It costs an afternoon to implement on your hottest endpoints and typically recovers 60-70% of the overhead.

// The dual-client pattern — production-tested approach
//
// prisma.ts — your Prisma client for convenience operations
import { PrismaClient } from '@prisma/client';
export const prisma = new PrismaClient();

// db.ts — raw pg pool for performance-critical paths
import pg from 'pg';
export const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
  max: 15,
  idleTimeoutMillis: 30000,
});

// api/users/[id]/route.ts — hot path, use pg directly
import { pool } from '@/db';

export async function GET(req, { params }) {
  const { rows } = await pool.query(
    'SELECT id, name, email, avatar_url FROM "User" WHERE id = $1',
    [params.id]
  );
  if (!rows.length) return new Response(null, { status: 404 });
  return Response.json(rows[0]);
}

// api/admin/users/route.ts — admin panel, Prisma is fine
import { prisma } from '@/prisma';

export async function GET(req) {
  const users = await prisma.user.findMany({
    include: { profile: true, _count: { select: { orders: true } } },
    orderBy: { createdAt: 'desc' },
    take: 50,
  });
  return Response.json(users);
}

The principle is straightforward: use Prisma where its developer experience justifies the overhead (admin panels, background jobs, low-traffic endpoints) and bypass it where performance matters (API hot paths, real-time features, high-concurrency endpoints). Both clients share the same database. Both use the same connection string. The only difference is the path the SQL takes to get there.

The trade-off is that you now maintain two data access patterns in the same codebase. The hot-path queries in raw pg do not benefit from Prisma's type generation, middleware, or logging. For teams that have invested heavily in Prisma middleware for audit logging, multi-tenancy, or soft deletes, the dual-client pattern means reimplementing those concerns for the raw pg paths. This is not trivial, and it should be factored into the decision.

Mitigation 2: Use $queryRaw for critical queries

// Mitigation 1: Use Prisma's interactive transactions sparingly
// (This does NOT fix implicit wrapping — it is always there)

// Mitigation 2: Use $queryRaw for hot paths
const users = await prisma.$queryRaw`
  SELECT id, name, email FROM "User" WHERE id = ${userId}
`;
// Still wraps in BEGIN/SELECT 1/COMMIT, but at least
// the query itself is your optimized SQL.

// Mitigation 3: Use a different client for hot paths
import pg from 'pg';
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });

// Hot path — bypass Prisma entirely:
const { rows } = await pool.query('SELECT id, name FROM "User" WHERE id = $1', [42]);

// Cold paths — Prisma is fine here:
const newUser = await prisma.user.create({ data: { name: 'Ada', email: 'ada@example.com' } });

The $queryRaw escape hatch lets you write raw SQL through Prisma. It still wraps in BEGIN/SELECT 1/COMMIT, so the round-trip overhead remains, but your query itself is your optimized SQL rather than Prisma's generated SQL. This is useful when the overhead is partially caused by Prisma's SQL generation (over-selecting columns, unnecessary JOINs) rather than solely by the transaction wrapping.

Mitigation 3: Consider Drizzle or Kysely for new projects

// The same query using node-postgres (pg):
import pg from 'pg';
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });

const { rows } = await pool.query(
  'SELECT id, name, email FROM "User" WHERE id = $1',
  [42]
);

// What hits PostgreSQL:
//   SELECT id, name, email FROM "User" WHERE id = $1
//
// One round trip. No BEGIN. No SELECT 1. No COMMIT.
// Autocommit handles the implicit transaction.

// The same query using Drizzle ORM:
import { eq } from 'drizzle-orm';
import { users } from './schema';

const user = await db.select().from(users).where(eq(users.id, 42));

// What hits PostgreSQL:
//   SELECT "id", "name", "email" FROM "users" WHERE "id" = $1
//
// One round trip. Drizzle compiles to SQL and sends it directly.
// No engine sidecar. No implicit transaction wrapping.

// Kysely — another alternative worth mentioning
import { Kysely, PostgresDialect } from 'kysely';
import pg from 'pg';

const db = new Kysely({
  dialect: new PostgresDialect({
    pool: new pg.Pool({ connectionString: process.env.DATABASE_URL }),
  }),
});

const user = await db
  .selectFrom('User')
  .select(['id', 'name', 'email'])
  .where('id', '=', 42)
  .executeTakeFirst();

// What hits PostgreSQL:
//   SELECT "id", "name", "email" FROM "User" WHERE "id" = $1
//
// One round trip. Kysely builds SQL and sends it via node-postgres.
// Full TypeScript type safety. No sidecar. No implicit transactions.
// Trade-off: no automatic migrations (use a separate migration tool).

If you are starting a new project and performance matters, the benchmarks speak clearly: Drizzle and Kysely give you type safety and ergonomic query building without the architectural overhead that makes Prisma slow. Drizzle offers a more ORM-like experience with schema definitions and relations. Kysely offers a SQL-first query builder that maps closely to the SQL you would write by hand. Both generate a single SQL statement and send it directly to PostgreSQL via node-postgres.

The trade-off versus Prisma is real: neither offers Prisma Studio, Prisma's migration UX is arguably more polished, and Prisma's schema DSL is more approachable for developers new to databases. If those tools are important to your team, the dual-client pattern from Mitigation 1 lets you keep them while bypassing the overhead on critical paths.

Mitigation 4: Prisma Accelerate for read-heavy workloads

// Prisma Accelerate — Prisma's hosted connection pooler/cache
//
// Prisma Accelerate sits between your app and your database,
// providing connection pooling and an optional query cache.
//
// What changes:
//   Your app → Prisma Engine → Prisma Accelerate → PostgreSQL
//
// What does NOT change:
//   The Engine still sends BEGIN / SELECT 1 / query / COMMIT.
//   Accelerate pools the connections, but the 4x statement
//   amplification still exists between Engine and Accelerate.
//   You are pooling overhead statements, not eliminating them.
//
// The cache is the real value:
const user = await prisma.user.findUnique({
  where: { id: 42 },
  cacheStrategy: {
    ttl: 60,         // cache for 60 seconds
    swr: 120,        // stale-while-revalidate for 120 seconds
  },
});
// Cache hit: ~1-5ms (served from Accelerate's edge)
// Cache miss: same overhead as before, plus the Accelerate hop
//
// Accelerate is useful for read-heavy workloads with cache-friendly
// access patterns. It does not address the fundamental overhead
// for write operations or cache-miss reads.

Prisma Accelerate is Prisma's hosted connection pooler and edge cache. For read-heavy applications with predictable access patterns, the caching layer can return results without hitting PostgreSQL at all — effectively bypassing the overhead for cache hits. The connection pooling component helps with pool exhaustion under load.

I should be precise about what Accelerate does and does not do. It does not eliminate the BEGIN/SELECT 1/COMMIT pattern. On a cache miss, the full 4x amplification still occurs between the Accelerate proxy and your database. What it does is add a caching layer that, for cache-friendly reads, avoids hitting the database entirely. This is genuinely useful for dashboard-style applications with high read volumes and tolerance for slightly stale data. It is less useful for write-heavy workloads, real-time features, or any path where cache-miss latency matters.

When Prisma's overhead does not matter

I have been thorough about the problem, and I owe you equal thoroughness about when the problem is irrelevant.

Internal tools and admin panels. If your application serves a team of 20 people and handles 5 requests per second, Prisma's overhead adds 3ms per query to a response that is probably already 200ms due to rendering, authentication, and business logic. The overhead exists. Nobody will notice.

Background jobs and batch processing. A queue worker that processes 100 jobs per minute can afford 4x statement amplification. The job processing time is dominated by the business logic, not by the database round trips. The extra 3ms per query is noise within a job that takes 500ms.

Applications where developer velocity is the primary constraint. If your team ships features 2x faster with Prisma than without it, and your application's latency requirements are generous (200ms+ response time budgets), the per-query overhead is a reasonable price for the velocity gain. Time-to-market has real economic value, and Prisma's developer experience delivers it.

Prototypes and MVPs. If you are validating a product hypothesis and will likely rewrite the data layer within a year regardless, optimize for speed of development, not speed of queries. Prisma excels here. You can always migrate to Drizzle or raw pg when — and if — query performance becomes the binding constraint.

The honest assessment: Prisma's overhead matters when your application is query-latency-sensitive, high-throughput, or both. For everything else, it is a tax you can afford to pay for excellent tooling. The mistake is not using Prisma. The mistake is using Prisma and being surprised by the overhead when latency starts to matter.

What a proxy sees that your application cannot

Here is an observation that may reframe the problem. From your application's perspective, you call prisma.user.findUnique() and get a result. You see one operation. From PostgreSQL's perspective, four statements arrive: BEGIN, SELECT 1, the query, COMMIT. PostgreSQL sees four operations.

Neither perspective captures the full picture. Your application does not know about the overhead statements. PostgreSQL does not know they are overhead — it processes them earnestly, acquiring snapshots, managing transaction state, updating statistics.

Gold Lapel sits between the two, observing every statement as it crosses the wire. It sees the BEGIN/SELECT 1/COMMIT pattern. It sees the 4x statement amplification. It sees the connection hold time. And it sees the actual business query in context — is it hitting an index? Is it scanning more rows than necessary? Is it one of 200 identical queries that could be answered from a materialized view?

The overhead statements are visible. The connection utilization impact is measurable. And the actual query, once isolated from the ceremony surrounding it, can be optimized on its own merits — indexed, rewritten, or materialized as needed. The proxy does not need your ORM to be efficient. It makes the queries efficient regardless of how they arrive.

Four statements per query is not ideal. But when the query itself runs in 0.3ms instead of 12ms because the right index exists, the 3ms of Prisma overhead becomes a smaller fraction of a much smaller total. Address the query performance first. The overhead, while real, becomes proportionally less painful.

The state of play, and where things are headed

Prisma is aware of the overhead. The GitHub issues are open, acknowledged, and actively discussed by the engineering team. There are indications that future versions of the Prisma Engine may make the healthcheck and transaction wrapping configurable or conditional — applying them only when the operation genuinely requires transactional semantics. I have not seen a committed timeline for these changes, but the recognition that the overhead exists is the necessary first step.

In the meantime, the Node.js ORM landscape has shifted. Drizzle, Kysely, and the improved type support in node-postgres itself (via pgtyped and @pgkit/client) offer type-safe database access without the sidecar overhead. These tools did not exist when Prisma was first adopted by many teams. They exist now, and they are mature enough for production use.

The advice I offer to a guest who arrives with this problem is situational. If you are starting a new project and performance is a requirement, Drizzle or Kysely will serve you well. If you are invested in Prisma and satisfied with its developer experience, the dual-client pattern lets you keep Prisma where it shines and bypass it where it costs too much. And if you are debugging a production latency issue right now and suspect Prisma is the cause, open pg_stat_statements, look for the BEGIN/SELECT 1/COMMIT pattern, and count the calls. The evidence will be unambiguous.

If you'll follow me, I believe the relationLoadStrategy investigation will also be of interest. The LATERAL JOINs Prisma uses for relation loading are a separate performance conversation — equally worth having, and rather more subtle than the one we have just concluded.