Why Bun SQL on Vercel throws unnamed prepared statement errors with Supabase

[mattparkerdev-9207 (Finton)]

Problem

We are seeing intermittent production database failures on Vercel when using the Bun runtime with Drizzle ORM and the Bun SQL driver against Supabase Postgres.

The error appears across normal application queries and results in HTTP 500 responses. A representative error is:

Error:

HTTPError: Failed query: select xxxx = $1

cause: PostgresError: unnamed prepared statement does not exist
code: ERR_POSTGRES_SERVER_ERROR
errno: 26000
routine: exec_bind_message

Current setup

• Runtime: Bun on Vercel
• ORM: Drizzle
• Driver: drizzle-orm/bun-sql
• Database: Supabase Postgres
• Client config: includes prepare: false
• Observed Version: Vercel using Bun 1.3.6 in deployment/runtime logs

Why this is unexpected

We already disabled prepared statements in the Bun SQL client:

const client = new SQL({
  url: process.env.DATABASE_URL,
  prepare: false,
  strict: true,
});

Despite that, the runtime still intermittently fails with unnamed prepared statement does not exist.

Suspected cause

This appears related to Bun SQL behavior on older Bun versions when prepare: false is used with pooled Postgres connections. My understanding is that newer Bun releases include a fix for unnamed prepared statements against PgBouncer/Supavisor-style pooling, but Vercel seems to be running Bun 1.3.6 for this deployment path.

Because Vercel currently documents bunVersion: "1.x" rather than exact patch pinning, we cannot explicitly force Bun 1.3.11+ ourselves.

What we need help with

1. Can you confirm which Bun patch version is actually being used for our Vercel deployment/runtime?
2. Does Vercel’s Bun runtime currently support the Bun SQL fix for unnamed prepared statements with pooled Postgres connections?
3. If not, is there a way to opt this project into a newer Bun patch version?

Impact

• Intermittent production HTTP 500s
• Failures affect standard read queries
• Issue is not deterministic, which makes it difficult to mitigate at the application layer

Mitigations

1. I am unable to use NodeJS runtime due to use on Bun SQL
2. I prefer not to use another NodeJS driver, and would like to stick with Bun SQL

[jacobparis]

It looks like prepare: false just changes Bun from using Named Prepared Statements to Unnamed Prepared Statements, which is an intentional thing on their end, therefore removing this flag (setting it to true) might get you around the issue

​Prepared Statements - SQL - Bun

Do you have a source for your suspected 1.3.11+ fix that I can share with the Bun team? I can confirm that the bun runtime version is non-configurable and we release regular updates, but I’ll have to ask to see when the next bump is planned

[mattparkerdev-9207 (Finton)]

Hi @jacobparis; appreciate the quick response, thank you.

Unforunately the problem is that prepared statements cannot be used at all, so changing to prepared: true results in the same issue (it’s just the statements are named when true).

Bun 1.3.11 release note states the following:

Fixed PgBouncer incompatibility with sql.prepare(false) queries

I believe this would fix my issue, and appears to have fixed it locally.

[jacobparis]

Thanks for the extra info, I confirmed with Bun team we are planning to bump bun to 1.3.11 in the next week

Recent public tweet on the topic:https://x.com/tomlienard/status/2040178314787082275?s=20

[jacobparis]

Bun 1.3.11 should be rolled out to all users in the next 3-4 hours, most teams are already flagged into it so it may already be turned on for your team, so if you redeploy hopefully everything is fixed

We do a staged rollout just to catch any issues but generally with the bun upgrades everything goes smoothly. Let me know if you’re still having troubles here