Does turning off prepared statements slow the app down?

Supabase recommends it for the transaction pooler, which is what serverless apps should use. If you need them, use the session pooler or a direct connection instead.

Other libraries show the same error. Same fix?

The same cause. Supabase’s troubleshooting page says to turn off prepared statements in your client, and links the setting for each library.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

Prisma “Prepared Statement Already Exists”?

Supabase and Prisma errorPrisma: “prepared statement "s0" already exists” on Supabase

The app works, then requests fail at random in production with prepared statement "s0" already exists, or does not exist. Prisma is talking to Supabase’s transaction pooler, which doesn’t support the prepared statements Prisma creates in the background. The fix is one setting in the connection string. Here it is in Supabase’s words, or hand it over at a fixed price.

Short answer

Add pgbouncer=true to the DATABASE_URL that points at the transaction pooler (port 6543), so Prisma stops creating prepared statements, then redeploy. Keep DIRECT_URL on the session pooler (port 5432) for migrations, which supports them. Check every place the app reads DATABASE_URL, including preview and production settings on your host.

Why it happens, and the fix

01
Transaction mode doesn’t support prepared statements
“The shared pooler doesn't support prepared statements in transaction mode.” Supabase, Error: prepared statement "XXX" already exists
In transaction mode, each query can run on a different database connection, so a prepared statement Prisma made on one connection clashes with another. That is why it fails at random rather than every time.
02
Add pgbouncer=true to the pooler string
“Add pgbouncer=true to the connection string. This turns off prepared statements in Prisma.” Supabase, Prisma troubleshooting
Append it to the DATABASE_URL on port 6543. If the string already has parameters, add it with an ampersand.
```
DATABASE_URL="postgres://postgres.[PROJECT-REF]:[PASSWORD]@[POOLER-HOST]:6543/postgres?pgbouncer=true"
```
03
Or use a connection that supports them
“Connect with a direct connection, or with the shared pooler in session mode, on port 5432. Both support prepared statements.” Supabase, Error: prepared statement "XXX" already exists
A long-running server can connect through the session pooler or a direct connection instead. Serverless functions should stay on the transaction pooler with prepared statements off.

Checked against the vendor’s docs on November 4, 2026: Supabase troubleshooting: prepared statement already exists; Supabase docs: Prisma troubleshooting; Supabase docs: Connect to your database.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Supabase and Prisma errorPrisma: “prepared statement "s0" already exists” on Supabase

Why it happens, and the fix

Transaction mode doesn’t support prepared statements

Add pgbouncer=true to the pooler string

Or use a connection that supports them

Rather hand it over?

More on this error

Describe it and get a written quote