prepared statement

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: # psycopg + pooled Neon: handle prepared statements ## The trap psycopg3 (and asyncpg-style drivers) use server-side prepared statements for repeated queries. Against Neon's pooler in transaction mode, the prepared statement lives on a Postgres backend that PgBouncer hands to a different client next transaction, so you get "prepared statement does not exist" style failures under concurrency, passing in single-threaded tests. ## The rule Two supported options, from Neon's pooling semantics: 1.

Fix

1. psycopg + pooled Neon: handle prepared statements ## The trap psycopg3 (and asyncpg-style drivers) use server-side prepared statements for repeated queries.

   Expected: this specific failure stops.

2. Use the direct connection string for anything that relies on prepared statements. Expected: the request routes instead of erroring.

3. Or disable client-side preparation (psycopg3:. Expected: this specific failure stops.

Details

Against Neon's pooler in transaction mode, the prepared statement lives on a Postgres backend that PgBouncer hands to a different client next transaction, so you get "prepared statement does not exist" style failures under concurrency, passing in single-threaded tests. ## The rule Two supported options, from Neon's pooling semantics: 1. 2. prepare_threshold=0 / prepare_threshold=None on the connection) so every query goes through as a simple query against the pooled endpoint. ## Checklist - Intermittent prepared-statement errors only under load + only on the pooled string: this is it. - SQLAlchemy users: this is separate from pool_pre_ping ; you can need both. - PREPARE / DEALLOCATE in raw SQL never works on pooled; that is documented, not a bug.

When to use

You hit exactly this: psycopg + Neon pooler: disable prepared statements or go direct in psycopg + Neon pooler.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

psycopg + Neon pooler.

Root cause

Session state survives because there is no pooler in the middle.

Neon's pooling docs (verified live 2026-09-26): PREPARE/DEALLOCATE (SQL-level prepared statements) are in the documented unsupported list for pooled connections in transaction mode; direct connections have no pooler in the middle.