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

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...

AJR•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...

AJR•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...

AJR•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
      },
    };

AJR•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...

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

thanks, I will dm you

AJR•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!

johtso•8/12/25, 12:35 PM

Is it usually possible to get maximum query (statement) duration limit increased? What's a reasonable limit that might be accepted? Currently running some fairly beefy KPI queries and started hitting the 60s timeout.. and now all of our internal tools have stopped working

I've just submitted a limit increase request if anyone is able to help

jins•8/12/25, 7:49 PM

I have some workers connected to external postgres database, should I be connecting through Hyperdrive to the external postgres db?

Jjins I have some workers connected to external postgres database, should I be connect...

AJR•8/12/25, 7:52 PM

Depends on your use case, but generally yes.

Focux•8/13/25, 7:32 PM

any idea what am i getting this error? i'm using MySQL + drizzle and not using multi-statement queries

Error: Hyperdrive does not currently support MySQL multi-statement queries"

Error: Hyperdrive does not currently support MySQL multi-statement queries"

Focux•8/13/25, 7:32 PM

hyperdrive id 565d1f80b5cf490286cd6a9d850be089

Xxetic User agents in MySQL statements trigger `Error: Hyperdrive does not currently su...

Focux•8/13/25, 7:52 PM

I think I'm having exactly the same issue, how did you fix it?

Focux•8/13/25, 7:55 PM

seems that the semicolon (

) is triggering the error

AJR•8/13/25, 8:19 PM

We have a ticket open to address that, will be fixed before MySQL support goes GA.

Focux•8/13/25, 9:00 PM

I would've expected a faster fix, especially since it's a pretty critical bug and there's still no date for the GA AFAIK.

Focux•8/13/25, 9:00 PM

Thank you anyway!

FFocux any idea what am i getting this error? i'm using MySQL + drizzle and not using m...

Isaac McFadyen•8/13/25, 9:13 PM

If you control the client code as a temporary workaround you could replace

in the user agent when inserting and then reverse that from

when selecting. Not ideal but would unblock you for now.

Focux•8/13/25, 9:17 PM

yeah, the user-agent is honestly the least of my worries, my app deals with large text blocks

Focux•8/13/25, 9:18 PM

and those could contain semicolons as well

FFocux I would've expected a faster fix, especially since it's a pretty critical bug an...

AJR•8/13/25, 9:54 PM

You know what, that's perfectly reasonable. Let me see if I can knock this one out for our next release.

AAJR You know what, that's perfectly reasonable. Let me see if I can knock this one o...

Focux•8/13/25, 9:55 PM

Thanks so much! I’d really appreciate it!

zsilbi•8/14/25, 10:34 AM

Hello!

I've started to experiment with Hyperdrive +

mysql2

mysql2

but I've ran into memory leak problems just by running the

SHOW TABLES

SHOW TABLES

example from the Hyperdrive tutorial (https://developers.cloudflare.com/hyperdrive/examples/connect-to-mysql/#mysql2)

I've created a new Nitro

eventHandler

eventHandler

with the example code and ran the it 25 times and noticed that the

Connection

Connection

objects are not collected by GC.

Interestingly, if change the the query to only run a single

SELECT

SELECT

on a table, the connection is closed and collected by GC.

I tried to run more complex queries using

drizzle

drizzle

and had the same issue.

Zzsilbi Hello! I've started to experiment with Hyperdrive + `mysql2` but I've ran into ...

AJR•8/14/25, 11:22 AM

Hi!

I'm not familiar with Nitro at all, so I'm going to have to ask what are likely dumb questions. Please bear with me.

Is this running on a Cloudflare Worker, or some other platform?
Do you see this behavior when using
```
mysql2
```
```
mysql2
```
without Hyperdrive? Or is this only visible when using both together?

zsilbi•8/14/25, 11:26 AM

I build the app using Nitro and run it using

wrangler dev .output/server/index.mjs --assets .output/public --env development --remote

wrangler dev .output/server/index.mjs --assets .output/public --env development --remote

I haven't tested it without Hyperdrive yet, that's what I am going to do now.

AJR•8/14/25, 11:28 AM

Ah. Local dev does not behave like production Hyperdrive today. It's basically just a TCP connect to your local database. It's a known challenge and we (Workers teams in general) have some roadmap items to improve it.

I expect, then, that you'll see the same behavior without Hyperdrive.

zsilbi•8/14/25, 11:29 AM

As I mentioned, the interesting thing is that if change

SHOW TABLES;

SHOW TABLES;

to just a

SELECT * FROM my_table;

SELECT * FROM my_table;

it works as expected. Each request has a new Connection which is cleared up in

waitUntil

waitUntil

AJR•8/14/25, 11:31 AM

That is interesting. We're collecting feedback on MySQL in our ecosystem, and the mysql2 maintainers have been very willing to work with us to improve support on our platform, so even if it's driver-only behavior it's still very good to know.

AJR•8/14/25, 11:31 AM

Also, for what it's worth, in production the Worker runtime will forcibly garbage-collect those, even if the driver itself leaves them open once the request finishes.

zsilbi•8/14/25, 11:35 AM

Thanks for the info, I'll do more tests to collect more data about this.
I'll also try this in staging to see if I can trigger an out of memory situtation.

AJR•8/14/25, 11:36 AM

Thank you! Looking forward to hearing what you see.

zsilbi•8/14/25, 11:47 AM

I ran it without Hyperdrive and the result is the same as expected.
I also built the app for

node

node

and tested the same event handler. The GC cleared the

Connection

Connection

after each request, so no issues there.
So this problem is not HD related at all.

AJR•8/14/25, 1:43 PM

Thanks for double-checking, much appreciated!

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; };

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

Similar Threads

Similar Threads

Similar Threads