I'm afraid it won't work. The connection string provided by the Hyperdrive binding is generated at r

I'm afraid it won't work. The connection string provided by the Hyperdrive binding is generated at runtime and is scoped to just that request. It won't work anywhere else or at any other time.

AJROP•7/17/25, 9:45 PM

Part of the security model.

AAJR I'm afraid it won't work. The connection string provided by the Hyperdrive bindi...

Isaac McFadyen•7/18/25, 12:35 AM

Interesting, if a connection is kept open (i.e. a global connection against recommendations of closing it at the end of a request) will it continue to work until it's closed then?

IIsaac McFadyen Interesting, if a connection is kept open (i.e. a global connection against reco...

AJROP•7/18/25, 12:54 AM

I'm not an expert in how the Worker Runtime manages state in edge cases like that, honestly. What I know for sure is that when the connection goes the connectionString goes with it

andrzej•7/18/25, 10:45 AM

Hi! I'm working on some Worker code which needs to fetch about a 1000 of small rows from a MySQL database (hosted by PlanetScale). When I connect using Hyperdrive, the CPU usage per request is way higher than when connecting directly. For example, 5ms with a direct connection, compared to 40ms with Hyperdrive.
The root cause - to my understanding - is the fact that when receiving data from Hyperdrive, each resulting row (mysql protocol packet) is returned in what appears to be a separate TCP packet. In my tests, each call to ReadableStreamBYOBReader.read returns only 22 bytes when receiving query results (this matches the size of the mysql packet), despite having lots of free space in the buffer.
I find this surprising, because conventional TCP mechanisms such as Nagle's algorithm should merge these small packets. If my understanding is correct, then this behaviour also introduces inefficiencies at other OS/network layers.
For comparison, when I connect directly to planetscale, the data is returned in much larger chunks (multiple kilobytes), allowing for more efficient processing.
A dirty workaround is to simply add a delay before receiving the query result. This allows one read() call to process a larger chunk of data.

AJROP•7/18/25, 11:07 AM

That's so interesting.

The underlying cause here is that under the hood Hyperdrive isn't TCP except for the very last hop to/from the origin database. The overwhelming majority of the transit uses different transport.

I'll make a ticket to investigate our batching to see if we can't improve it to at least parity with a direct connection. We focused far more on latency and throughput for the beta, and our Postgres handler has a bunch of other buffering built in by nature of the protocol. However we definitely don't want to be running up CPU time on MySQL either.

Thanks for bringing this to our attention.

AJROP•7/18/25, 11:07 AM

Fyi @thomasgauvin ^

Aandrzej Hi! I'm working on some Worker code which needs to fetch about a 1000 of small r...

AJROP•7/18/25, 3:35 PM

Which drivers are you using for Hyperdrive and the direct connection to Planetscale?

andrzej•7/18/25, 4:12 PM

I've started with mysql2, but then I've moved to a handcrafted mysql protocol implementation, hoping to avoid any unnecessary CPU overheads.

Aandrzej I've started with mysql2, but then I've moved to a handcrafted mysql protocol im...

AJROP•7/18/25, 4:14 PM

Sounds good. Wanted to make sure that the difference was visible even with the same driver, to rule out having to explore driver-level differences also. Thank you!

dave•7/21/25, 1:19 PM

Error: write CONNECTION_CLOSED REMOVED.hyperdrive.local:5432

Error: write CONNECTION_CLOSED REMOVED.hyperdrive.local:5432

Got a few of these last night.

dave•7/21/25, 1:32 PM

Is there a way I should be retrying connections with postgres.js to avoid the request from completely failing?

AJROP•7/21/25, 2:41 PM

We do encourage application-level retries, yes. Hyperdrive will in the near future do some amount of internal retrying on non-volatile reads, but in general we will always have to be conservative with that given the limited scope of information available. Application-level will likely always be able to do better.

omar•7/21/25, 7:30 PM

Adding hyperdrive to our MySQL database on planetscale resulted in higher latency

surgery18•7/22/25, 5:05 PM

So I am getting this strange issue now. My workers were working fine till today. All of the sudden it is throwing the error "Hyperdrive does not currently support MySQL multi-statement queries" Did Cloudflare do an update to hyperdrive and it broke it? Nothing is saving now.

Ssurgery18 So I am getting this strange issue now. My workers were working fine till today....

AJROP•7/22/25, 5:07 PM

Hyperdrive has not supported multi-statement queries in MySQL since the beta launched, that hasn't changed. Did they used to work for you?

surgery18•7/22/25, 5:09 PM

So the statement was working for me for a while

await connection2.query("INSERT into revolv_events SET ? ON DUPLICATE KEY UPDATE ?", [ins, ins])

await connection2.query("INSERT into revolv_events SET ? ON DUPLICATE KEY UPDATE ?", [ins, ins])

. It was saving into the db and everything just perfectly. Just today it stopped saving and instead throw that error.

Ssurgery18 So the statement was working for me for a while `await connection2.query("INSERT...

AJROP•7/22/25, 5:10 PM

We're taking a look. We have been collecting MySQL feedback from the beta (and investigating some of the feedback given here in particular) but haven't made any changes to it yet.

surgery18•7/22/25, 5:12 PM

Ok, in the meantime what do you suggest I do if that query doesn't work? Just do a regular insert and surround with try/catch without the dup key thing?

Ssurgery18 Ok, in the meantime what do you suggest I do if that query doesn't work? Just do...

AJROP•7/22/25, 5:14 PM

For now, if that works for you, yes. We're still taking a look to see if anything changed unintentionally.

AAJR For now, if that works for you, yes. We're still taking a look to see if anythin...

surgery18•7/22/25, 5:14 PM

Ok.

Ssurgery18 Ok.

AJROP•7/22/25, 5:15 PM

What driver are you using, and any ORMs with it?

AAJR What driver are you using, and any ORMs with it?

surgery18•7/22/25, 5:16 PM

Using the driver mysql2 and no ORM.

AJROP•7/22/25, 5:17 PM

Okay. Hmmm. Mind sharing your Hyperdrive ID?

AAJR Okay. Hmmm. Mind sharing your Hyperdrive ID?

surgery18•7/22/25, 5:17 PM

Sure, I will DM you it so you can look into it.

surgery18•7/22/25, 5:19 PM

DM sent.

AsyncBanana•7/24/25, 9:56 PM

For whatever reason, hyperdrive registers almost exactly 2/3 of my queries as uncacheable. All of my queries (using postgres.js) are selects outside of a transaction that do not use any volatile functions. To make matters even more confusing, I separated each query type into its own hyperdrive connection, and they all had a 2/3 uncacheable rate. Any ideas why this is happening?

NNeves I'm using mysql2 to connect to planet scale dev database locally, but I'm gettin...

AJROP•7/25/25, 11:37 AM

Local connections to remote databases are a challenge due to binding limitations. It's on our radar and there's some org-wide work going into addressing it, but it will be a while yet.

AAsyncBanana For whatever reason, hyperdrive registers almost exactly 2/3 of my queries as un...

AJROP•7/25/25, 11:39 AM

If you wouldn't mind sharing your Hyperdrive ID I can take a look.

Also, sharing for general information, the full granularity of cacheability status for all of your queries are available via our graphQL endpoint. Thata's worth checking as it'll have more detail than the graphs on the dashboard.

NNeves For now I can switch to direct connection locally. Is there a best way to know I...

AJROP•7/25/25, 11:44 AM

I believe env vars are the way folks usually handle that. something like:

    export default {
      async fetch(request, env, ctx) {
        if (env.DEV) {
          // Logic specific to local development
          console.log("Running in local development mode.");
        } else {
          // Logic specific to production
          console.log("Running in production mode.");
        }
        // ... rest of your Worker logic
      },
    };

    export default {
      async fetch(request, env, ctx) {
        if (env.DEV) {
          // Logic specific to local development
          console.log("Running in local development mode.");
        } else {
          // Logic specific to production
          console.log("Running in production mode.");
        }
        // ... rest of your Worker logic
      },
    };

AJROP•7/25/25, 11:45 AM

Ah, found a very simple blog showing it off (apologies for no docs link, on my phone and don't have it handy)
https://www.fabiofranchino.com/log/how-to-detect-a-cloudflare-worker-in-dev-local-mode/

AAJR If you wouldn't mind sharing your Hyperdrive ID I can take a look. Also, shar...

AsyncBanana•7/25/25, 12:11 PM

thanks, I will dm you

AJROP•7/25/25, 8:55 PM

Yeah, it does. Hyperdrive will place your connection pool near your database on creation, but smart placement for where your Worker itself runs takes quite a lot of traffic to converge, as I understand it

AAJR Yeah, it does. Hyperdrive will place your connection pool near your database on ...

thomasgauvin•7/25/25, 9:54 PM

That's correct, smart placement will look at Cloudflare locations with decent amount of distributed traffic and will determine from those which is best to host your app.

It takes some amount of production traffic for things to kick in

letincho5•7/27/25, 2:07 PM

Hi, sorry if is not the correct channel...

We use this stack: Drizzle + Hyperdrive + Neon for full intensive processing.

Neon has the maximum configuration, with 4,000 connections (and 10,000 pooled).

In a production environment, we noticed that when we reached the limit of 4,000 (according to the Neon dashboard), we started getting a worker error saying "Timed out while waiting for an open slot in the pool."

And even though the system load had decreased, we still got the error and still saw 4,000 active connections in Neon. Only by forcing a restart of the pool connections (by lowering and raising the number of CPUs), Hyperdrive released the connections and the system recovered. However, upon its return, it was only using 100 connections. This suggests that the other 3,900 were never released.

The Hyperdrive configuration is using the Neon connection string used by its connection pool.

This is out drizzle's use:

const cnx1: Pool = new Pool({
host: hd.host,
user: hd.user,
password: hd.password,
port: Number(hd.port),
database: hd.database,
idleTimeoutMillis: 10000, (WE TRY WITH OTHERs TOO)
connectionTimeoutMillis: 5000,
min: 0, (WE TRY WITH 1, 5, etc)
max: 5, (WITH OTHERS too)
ssl: false,
});
return drizzle(cnx1);
We have an expected Hyperdrive configuration with a maximum soft-limit connection of 500. Our workers use 8 Hyperdrives in a round-robin strategy. This allows us to reach 4,000 active connections.

Thanks in advance Martín

letincho5•7/27/25, 2:08 PM

The feeling is that hyperdrive is not releasing connections.

Niveth•7/28/25, 7:48 AM

Hey there, we are facing high latency with hyperdrive.

Can we know in which datacenter our hyperdrive are running on ? These are the id's of our hyperdrive

d8646d64296b433ab021b32c4f3a66c9
be92bf0733d3475791987cd7ed539765

Our database is hosted on ap-south-1 which is nearby to cloudflare's BOM datacenter.

We have enabled smart placement but still we are consisently seeing 400ms+ latency.

Thanks for the help

Aditya Kresna•7/30/25, 3:28 AM

Hello

Does Hyperdrive supports connecting to PostgreSQL with TLS 1.3 (Ed25519)?

I got this error while configuring Hyperdrive via Zero Trust Tunnel:

Failed to connect to the provided database: TLS handshake failed [SSLV3_ALERT_HANDSHAKE_FAILURE] [HANDSHAKE_FAILURE_ON_CLIENT_HELLO]

Failed to connect to the provided database: TLS handshake failed [SSLV3_ALERT_HANDSHAKE_FAILURE] [HANDSHAKE_FAILURE_ON_CLIENT_HELLO]

Yk•8/1/25, 11:17 AM

Hello everyone! I'm trying to connect to supabase postgres instance from a worker via hyperdrive using this guide https://developers.cloudflare.com/hyperdrive/examples/connect-to-postgres/postgres-drivers-and-libraries/postgres-js/ . I'm using postgres.js 3.4.7. In local it works connecting to the same database the hyperdrive is using, but on cf i got CONNECTION_TIMEOUT hitting the 10s i configured always. If i just connect directly in cf i got "too many subrequests" after 1 or 2 secs (the function is very simple). Any ideas?

Cloudflare Docs

Postgres.js

Postgres.js is a modern, fully-featured PostgreSQL driver for Node.js. This example demonstrates how to use Postgres.js with Cloudflare Hyperdrive in a Workers application.

Voodoo262•8/7/25, 8:44 PM

Hey folks. I apologize if this question has already been asked. I recently updated my AWS RDS cluster from MySQL 8.0 to MySQL 8.4 and it looks like it's no longer compatible with Hyperdrive. Is this a known issue? Is there a workaround?

Hochul•8/8/25, 6:28 AM

I am using HyperDrive with my Postgres db in Oracle server located in Germany with Cloudflare workers. (I am also working n Germany)Connection is made and working without problem but the response is still slow(a bit faster than direct connection). Funny thing I found is it is very fast with mobile network while it is slow with my WiFi with same running contents. (200ms vs 2 seconds). Is this because HyperDrive needs some traffic to calculate? Right now I have no users as it is in dev. Thanks!

bloushi•8/10/25, 7:37 AM

Help: Zero Cache Hits – Hyperdrive Queries Bypassing Cache Straight to DB!

Hey team, I'm scratching my head over this caching mystery. Every query skips the cache and hits my Postgres DB directly (running on a Hetzner VPS), resulting in 0 cache hits for weeks. No performance magic happening here!

Quick Context:

Using Hyperdrive for connection pooling.
Drizzle queries are wrapped in a custom runWithDB function (code below). Reason: Prevent CF Workers from opening too many connections
Is this wrapper the culprit? If so, what's the fix to enable proper caching?
The Suspect Code: runWithDB Function

    export async function runWithDB<T>(
      context: unstable_RouterContextProvider,
      callback: (db: PostgresJsDatabase) => Promise<T>
    ): Promise<T> {
      const { HYPERDRIVE } = getBindings(context);
    
      const sql = postgres(HYPERDRIVE.connectionString, {
        prepare: false,
        max: 5,
        fetch_types: false,
        idle_timeout: 5,
        connect_timeout: 5,
        max_lifetime: 60,
      });
    
      try {
        const db = drizzlePostgresJs(sql);
    
        const result = await callback(db);
    
        return result;
      } catch (err) {
        console.log('err', err);
        throw err;
      } finally {
        const ctx = await getExecutionContext(context);
        ctx.waitUntil(sql.end());
      }
    }

    export async function runWithDB<T>(
      context: unstable_RouterContextProvider,
      callback: (db: PostgresJsDatabase) => Promise<T>
    ): Promise<T> {
      const { HYPERDRIVE } = getBindings(context);
    
      const sql = postgres(HYPERDRIVE.connectionString, {
        prepare: false,
        max: 5,
        fetch_types: false,
        idle_timeout: 5,
        connect_timeout: 5,
        max_lifetime: 60,
      });
    
      try {
        const db = drizzlePostgresJs(sql);
    
        const result = await callback(db);
    
        return result;
      } catch (err) {
        console.log('err', err);
        throw err;
      } finally {
        const ctx = await getExecutionContext(context);
        ctx.waitUntil(sql.end());
      }
    }

How I Use It (Example Query):

    export const getUserByEmailAddress = async (
      email: string,
      context: unstable_RouterContextProvider
    ) => {
      const [user] = await runWithDB(context, async (db: PostgresJsDatabase) => {
        return await db
          .select()
          .from(UserTable)
          .where(eq(UserTable.email, email))
          .limit(1);
      });
    
      return user;
    };

    export const getUserByEmailAddress = async (
      email: string,
      context: unstable_RouterContextProvider
    ) => {
      const [user] = await runWithDB(context, async (db: PostgresJsDatabase) => {
        return await db
          .select()
          .from(UserTable)
          .where(eq(UserTable.email, email))
          .limit(1);
      });
    
      return user;
    };

Any insights or tweaks to get those cache hits working again? Thanks a ton!

export default { async fetch(request, env, ctx) { if (env.DEV) { // Logic specific to local development console.log("Running in local development mode."); } else { // Logic specific to production console.log("Running in production mode."); } // ... rest of your Worker logic }, };

export async function runWithDB<T>( context: unstable_RouterContextProvider, callback: (db: PostgresJsDatabase) => Promise<T> ): Promise<T> { const { HYPERDRIVE } = getBindings(context); const sql = postgres(HYPERDRIVE.connectionString, { prepare: false, max: 5, fetch_types: false, idle_timeout: 5, connect_timeout: 5, max_lifetime: 60, }); try { const db = drizzlePostgresJs(sql); const result = await callback(db); return result; } catch (err) { console.log('err', err); throw err; } finally { const ctx = await getExecutionContext(context); ctx.waitUntil(sql.end()); } }

export const getUserByEmailAddress = async ( email: string, context: unstable_RouterContextProvider ) => { const [user] = await runWithDB(context, async (db: PostgresJsDatabase) => { return await db .select() .from(UserTable) .where(eq(UserTable.email, email)) .limit(1); }); return user; };

I'm afraid it won't work. The connection string provided by the Hyperdrive binding is generated at r

Similar Threads

Similar Threads

Similar Threads