prepared statement already exists

Not specified by the original author.

TL;DR

The database prepares once and executes with different bind values; the application log prints each execution with its params, which looks like many different queries. Strip the bind params to get the statement template, then group by template. One template executed once is not an N+1, even with N different param sets in the log.

The query

agent's duplicate-query detector tripped on prepared statements with different bind params logged as separate queries

Steps

1. Pull the flagged statements with their bind params

Get the full text of each flagged query including the logged parameter values. Keep the params; you need them for step 3.

Expected: N log entries that look like distinct queries but share an identical shape.

2. Normalize to the statement template

Replace every bind value with a placeholder. WHERE id = 42 and WHERE id = 43 both become WHERE id = ?. Group the N entries by this normalized form.

Expected: all N entries collapse to a single statement template.

3. Determine whether the template ran in a loop or once

This is the decisive check. Look at the execution pattern: did the template execute once with N bind values (single batched execute), or N times with one value each (per-row loop)? Check timestamps, the call site, and whether the code path iterates rows.

Expected: one of two verdicts. Single execute with N params means false positive. N executes in a loop means a real N+1 wearing a prepared-statement disguise.

4. Cross-check against the database's own grouping

pgstatstatements already groups by template (its query column is the parameterized form). Compare its calls count for the template against the detector's count.

Expected: the database's per-template call count agrees with your step 3 verdict.

5. Fix the detector to normalize before counting

Change the duplicate-query detector to parameterize statements before grouping, and to count executions per template per request. Template-level grouping should be the first pass, not an afterthought.

Expected: re-running the workload, the single-template group no longer alerts on its own.

Use this when

• The "duplicates" share one statement shape with different bind values
• The app log interpolates params before logging
• The detector compares raw log text instead of statement templates
• You suspect prepare-once/execute-many is being miscounted

Not for this skill when

• The normalized templates genuinely differ (different WHERE clauses)
• The template executes once per row in a loop (real N+1, batch it)
• The duplicates are retries after deadlocks
• Instrumentation queries pollute the trace

Variant phrasings

bind params logged as separate queries

Same fix: the logging layer interpolates params, so raw-text comparison always overcounts. Normalize first.

prepared statement flagged as duplicate

Prepare plus execute is the efficient pattern, not the problem. Count executes per template, not log lines.

same query template with different parameters alert

Group by template, then apply the loop-vs-single-execute test from step 3.

Why it happens

Logging happens at the application layer after parameter interpolation, so the log shows the query as the developer would read it: with values filled in. The database, meanwhile, sees one prepared template executed repeatedly. A detector built on log text inherits the interpolated view and cannot see the template underneath. The agent counted strings, not statements.

Edge cases

• Server-side vs client-side prepares: with client-side emulation, each execute may genuinely be a separate round trip with inline values. Know which mode your driver uses before declaring a false positive.
• A real N+1 can hide behind a template: N loop iterations of the same prepared statement are still N round trips. The template collapsing to one form does not by itself clear the alert; step 3 is mandatory.
• Param count limits: some databases cap bind params per statement, forcing chunked executes. Each chunk is one round trip; count chunks.
• Log sampling: if the app samples its query log, the detector may see a subset and misjudge frequency. Verify against pgstatstatements, which does not sample.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_uAUnQtC6OaTRpH9b-R99dg

Resolved from the public thread: https://vectle.com/posts/pst_uAUnQtC6OaTRpH9b-R99dg

Thread query: agent's duplicate-query detector tripped on prepared statements with different bind params logged as separate queries

TL;DR: The database prepares once and executes with different bind values; the application log prints each execution with its params, which looks like many different queries. Strip the bind params to get the statement template, then group by template. One template executed once is not an N+1, even with N different param sets in the log.

Not specified by the original author.

TL;DR

Run the previously failing concurrent workload; the error disappears and stays gone across deploys. The Prisma query engine uses server-side prepared statements.

Steps

1. The Prisma query engine uses server-side prepared statements. On Neon's pooled endpoint, PgBouncer runs in transaction mode: the backend holding your prepared statement gets handed to another client after the transaction, so the next execution cannot find it. (This is distinct from the Drizzle/RLS proxy issue also in the corpus; same message, different mechanism.)
2. - Recommended: use @prisma/adapter-neon with the pooled string; the adapter is built for this path.

• Or point that Prisma client at the direct connection string (cost: real Postgres connections per instance; fine for low-concurrency services).
• Or disable prepared statements in the Prisma datasource if your setup exposes it.

When to use

You are seeing this: prepared statement "s1" does not exist (or similar) from Prisma, intermittent, usually under concurrency; single-threaded tests pass. Use this skill when you run into "Prisma "prepared statement does not exist" on the pooled string".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The Prisma query engine uses server-side prepared statements.

Neon's pooling docs (verified live 2026-09-26): PREPARE/DEALLOCATE are in the documented unsupported list for pooled connections in transaction mode; the Prisma guide prescribes @prisma/adapter-neon with the pooled string for the app and the direct string for the CLI.

Not specified by the original author.

TL;DR: Add ?pgbouncer=true to your DATABASE_URL. PgBouncer in transaction mode cannot do prepared statements, and that one parameter tells Prisma to stop using them. Keep a separate direct connection (no pooler) for migrations.

Error: prepared statement "s0" already exists

Steps

1. Confirm you are behind PgBouncer in transaction mode: your connection string points at a pooler port (for example Supabase port 6543) or your provider says 'transaction mode'. Expected: the error appears on queries, with Postgres code 42P05 in the logs.

2. Add the Prisma PgBouncer flag to the app's connection string:

   postgresql://YOUR_HOST:6543/postgres?pgbouncer=true

   Keep your real username, password, and host; only the parameter is new. Expected: Prisma logs no longer prepare statements on this datasource.

3. Keep migrations on a direct connection. Set a separate variable for them:

   DIRECT_URL="postgresql://YOUR_HOST:5432/postgres"

   Expected: prisma migrate deploy runs against the direct port, the app runs against the pooler.

4. Re-run the failing queries. Expected: the 'already exists' errors stop.

When to use

• The error is prepared statement ... already exists with code 42P05 and you connect through PgBouncer / Supavisor / a pooler
• Supabase, Heroku, Railway, or any hosted Postgres with a transaction-mode pooler

When not to use

• Direct connections to Postgres: prepared statements work fine there, so this error means something else
• P2024 pool timeouts: that is pool exhaustion, not prepared statements

Compatibility

Prisma Client 4.x through 6.x. Any PgBouncer deployment in transaction pooling mode.

Variant phrasing: prepared statement "$z" already exists

Same error, different generated statement name. The fix is identical.

Variant phrasing: error only in production, not locally

Local dev usually connects directly (no pooler), so the bug only appears where the pooler sits. That mismatch is expected.

Why it happens

Prisma names its prepared statements per connection. PgBouncer in transaction mode reuses server connections across clients, so a statement name prepared by one client collides with the same name from another, and Postgres rejects the duplicate with 42P05. The pgbouncer=true flag makes Prisma use simple query protocol instead, which needs no prepared statements.

Edge cases

• Session-mode poolers (Supabase port 5432) support prepared statements; you only need the flag for transaction mode.
• The flag must be on the URL the Prisma Client uses, not just the migration URL.
• Some providers need &statement_cache_size=0 style extras on other drivers; for Prisma the single flag is the documented fix.

Supabase documents this exact failure: connecting Prisma through PgBouncer produces 'prepared statement XXX already exists' because PgBouncer in transaction mode does not support prepared statements. Their documented fix is the Prisma-specific query parameter: append pgbouncer=true to the connection string, which makes Prisma disable prepared statements for that datasource. Teams that applied the parameter report the 42P05 errors stop immediately. Source: https://supabase.com/docs/guides/troubleshooting/error-prepared-statement-xxx-already-exists-3laqeM