In terms of how you'd actually use them, if you wanted to port away, no not really. You have the op

AAJR In terms of how you'd actually use them, if you wanted to port away, no not real...

D

dave•12/16/24, 7:57 PM

Thanks! This is for new applications, where we want the option to let some enterprise customers self-host (without us needing to rewrite anything).

Ddave Is there any difference, in terms of programming, between using Hyperdrive vs. T...

T

thomasgauvin•12/16/24, 7:57 PM

@dave | ai.moda the main difference will be using the connectionString you get from Hyperdrive (ie env.HYPERDRIVE.connectionString) instead of env.connectionString accessed as a environment variable/secret.

F

Frank•12/17/24, 10:45 AM

getting 500 errors when trying to create hyperdrive connection

F

Frank•12/17/24, 10:51 AM

not sure if this means anything

A request to the Cloudflare API (/accounts/xxxxxxxxxxx/hyperdrive/configs) failed.
Internal Server Error [code: 10000]

A request to the Cloudflare API (/accounts/xxxxxxxxxxx/hyperdrive/configs) failed.
Internal Server Error [code: 10000]

A request to the Cloudflare API (/accounts/xxxxxxxxxxx/hyperdrive/configs) failed.
Internal Server Error [code: 10000]

A request to the Cloudflare API (/accounts/xxxxxxxxxxx/hyperdrive/configs) failed.
Internal Server Error [code: 10000]

F

Frank•12/17/24, 10:52 AM

UI did not work either

A

Abdul•12/17/24, 12:27 PM

Not able to connect my hyperdrive to my existing Neon DB with Drizzle ORM. WHY?

error when running

pnpm run dev

pnpm run dev

pnpm run dev

pnpm run dev

my

wrangler.toml

wrangler.toml

[[hyperdrive]]
binding = "HYPERDRIVE"
id = "<ID>"

i got the ID by running

npx wrangler hyperdrive create linkp-neon-hyperdrive --connection-string="

npx wrangler hyperdrive create linkp-neon-hyperdrive --connection-string="

npx wrangler hyperdrive create linkp-neon-hyperdrive --connection-string="

npx wrangler hyperdrive create linkp-neon-hyperdrive --connection-string="

output:

🚧 Creating 'linkp-neon-hyperdrive'
✅ Created new Hyperdrive config
 {
  "id": "<ID>",
  "name": "linkp-neon-hyperdrive",
  "origin": {
    "host": "ep-old-sky--pooler.ap-southeast-1.aws.neon.tech",
    "port": 5432,
    "database": "linkp-db",
    "scheme": "postgresql",
    "user": "hyperdrive-user"
  },
  "caching": {
    "disabled": false
  }
}

🚧 Creating 'linkp-neon-hyperdrive'
✅ Created new Hyperdrive config
 {
  "id": "<ID>",
  "name": "linkp-neon-hyperdrive",
  "origin": {
    "host": "ep-old-sky--pooler.ap-southeast-1.aws.neon.tech",
    "port": 5432,
    "database": "linkp-db",
    "scheme": "postgresql",
    "user": "hyperdrive-user"
  },
  "caching": {
    "disabled": false
  }
}

🚧 Creating 'linkp-neon-hyperdrive'
✅ Created new Hyperdrive config
 {
  "id": "<ID>",
  "name": "linkp-neon-hyperdrive",
  "origin": {
    "host": "ep-old-sky--pooler.ap-southeast-1.aws.neon.tech",
    "port": 5432,
    "database": "linkp-db",
    "scheme": "postgresql",
    "user": "hyperdrive-user"
  },
  "caching": {
    "disabled": false
  }
}

🚧 Creating 'linkp-neon-hyperdrive'
✅ Created new Hyperdrive config
 {
  "id": "<ID>",
  "name": "linkp-neon-hyperdrive",
  "origin": {
    "host": "ep-old-sky--pooler.ap-southeast-1.aws.neon.tech",
    "port": 5432,
    "database": "linkp-db",
    "scheme": "postgresql",
    "user": "hyperdrive-user"
  },
  "caching": {
    "disabled": false
  }
}

Then in my

src/index.ts

src/index.ts

i have created a middlware to attach my DB instance in my requests:

export const injectDB = createMiddleware(async (c, next) => {
  try {
    console.log(

export const injectDB = createMiddleware(async (c, next) => {
  try {
    console.log(

export const injectDB = createMiddleware(async (c, next) => {
  try {
    console.log(

export const injectDB = createMiddleware(async (c, next) => {
  try {
    console.log(

Connecting to database...${c.env.HYPERDRIVE.connectionString}


    );

    const sql = neon(c.env.HYPERDRIVE.connectionString);
 

    c.req.db = drizzle({ client: sql, schema });
    await next();
  } catch (error) {
    console.error("Database connection error:", error);
    throw new HTTPException(503, { message: "Database connection failed" });
  }
});


    );

    const sql = neon(c.env.HYPERDRIVE.connectionString);
 

    c.req.db = drizzle({ client: sql, schema });
    await next();
  } catch (error) {
    console.error("Database connection error:", error);
    throw new HTTPException(503, { message: "Database connection failed" });
  }
});


    );

    const sql = neon(c.env.HYPERDRIVE.connectionString);
 

    c.req.db = drizzle({ client: sql, schema });
    await next();
  } catch (error) {
    console.error("Database connection error:", error);
    throw new HTTPException(503, { message: "Database connection failed" });
  }
});


    );

    const sql = neon(c.env.HYPERDRIVE.connectionString);
 

    c.req.db = drizzle({ client: sql, schema });
    await next();
  } catch (error) {
    console.error("Database connection error:", error);
    throw new HTTPException(503, { message: "Database connection failed" });
  }
});

while drizzle is coming from

import { drizzle } from "drizzle-orm/neon-http";

import { drizzle } from "drizzle-orm/neon-http";

import { drizzle } from "drizzle-orm/neon-http";

import { drizzle } from "drizzle-orm/neon-http";

How can i solve this issue?

also tried using

Postgres

Postgres

Postgres

Postgres &

node-postgres

node-postgres

node-postgres

node-postgres instead of

neon-http

neon-http

neon-http

neon-http

D

dave•12/17/24, 6:26 PM

Is it safe to use

env.HYPERDRIVE.connectionString

env.HYPERDRIVE.connectionString

env.HYPERDRIVE.connectionString

env.HYPERDRIVE.connectionString in the global context?

S

Sandip•12/19/24, 12:19 PM

Stuck on runnig wrangler locally.

Implementing Hyperdrive with supabase but when doing

npx wrangler dev --remote

npx wrangler dev --remote

npx wrangler dev --remote

npx wrangler dev --remote

it gives error saying "No resposne".
using Remix js

F

Focux•12/20/24, 1:14 PM

any idea why querying directly to neon is faster than doing it thorugh hyperdrive?

F

Focux•12/20/24, 1:15 PM

i'm running the same query to compare them, one using postgresjs and hyperdrive and another one using neon serverless driver connecting directly to neon

F

Focux•12/20/24, 1:16 PM

30ms vs 120ms

FFocux any idea why querying directly to neon is faster than doing it thorugh hyperdriv...

A

AJROP•12/20/24, 1:58 PM

Where are you querying from, and where's your origin?

F

Focux•12/20/24, 2:01 PM

querying from a worker with smart placement, according to the response header the worker is on local-ATL

F

Focux•12/20/24, 2:01 PM

and db is located on us-east-1

A

AJROP•12/20/24, 2:01 PM

Caching enabled or disabled?

F

Focux•12/20/24, 2:01 PM

caching enabled

A

AJROP•12/20/24, 2:06 PM

Try without smart placement and without caching, let me know how that looks? Smart placement doesn't always cooperate with caching products. Caching will also be apples-to-oranges with a serverless driver that can't do that.

We (well, @thomasgauvin did all the actual work) recently did a quick comparison of a bunch of those serverless drivers and by and large found performance very comparable with those settings off, maaaaybe a slight edge to Hyperdrive today. If you're seeing that kind of gap even with those settings off I'd be very curious to figure out why.

As we roll out improvements, though, they'll mostly be of the kinds that serverless drivers can't take advantage of. Things like pool placement, caching improvements, etc. If it's still comparable in 3 months I'll be pretty surprised.

F

Focux•12/20/24, 2:17 PM

With cache disabled and smart placement now, the query times are more similar; the neon serverless driver seems to be 10-20ms faster

A

AJROP•12/20/24, 2:18 PM

Ok. That's within the ranges we were seeing. Thank you for checking.

Serveless drivers solve a lot of the same problems as Hyperdrive, in pretty different ways. At this time, we do expect perf to be comparable, though cache hits should obviously be faster today.

F

Focux•12/20/24, 2:19 PM

Yeah, that's the behavior I'm seeing. The average seems to be almost the same.

A

AJROP•12/20/24, 2:19 PM

Hyperdrive with caching disabled does ok with smart placement, but it's not as good as it could be. We have another big architecture change in progress that will improve that compatibility a good deal.

F

Focux•12/20/24, 2:21 PM

So, correct me if I'm wrong, but right now, the upside of using Hyperdrive seems to be the caching layer, right?

A

AJROP•12/20/24, 2:25 PM

Depends on your architecture and how widespread your userbase is.
Hyperdrive beats serverless drivers in the following ways today (again, this list is expected to grow in the near future, stay tuned):

caching layer, as you noted
automatic connection pooling, don't need to handle that yourself (not as big a deal if your service gives you one the same way)
uses portable drivers, don't have to build targeting only one origin service (e.g. neon, though we do love them)
uses CF network for a lot of the transit, which may be more reliable than the local public internet depending on where you are

F

Focux•12/20/24, 2:31 PM

Great work, it's 100% worth it using Hyperdrive today. I can't wait to see what you guys build next. I'm hoping to see MySQL support

. Although the node MySQL driver doesn't support Workers yet, haha

Y

Yu•12/23/24, 2:46 PM

I found that my hyperdriver was never able to connect to the remote library of supabase locally. The tutorial I referred to was

https://developers.cloudflare.com/hyperdrive/configuration/local-development/
and https://developers.cloudflare.com/hyperdrive/examples/supabase/

I am a normal worker among online workers. Has anyone encountered this problem before?

YYu I found that my hyperdriver was never able to connect to the remote library of s...

A

AJROP•12/23/24, 3:55 PM

Local dev mode (i.e.

wrangler dev

wrangler dev

) does not currently support connecting to remote databases that require SSL. It is a known gap that we are hoping to address in the future.

AAJR Local dev mode (i.e. `wrangler dev`) does not currently support connecting to re...

Y

Yu•12/23/24, 4:12 PM

So how do I test and debug locally? Is there any good practice?

A

AJROP•12/23/24, 4:16 PM

Couple options.

One is to have a local DB (I keep this alias in my bashrc:
```
docker run -d -e POSTGRES_PASSWORD=password -p 5433:5432 postgres:16 -c ssl=on -c ssl_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem -c ssl_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
```
docker run -d -e POSTGRES_PASSWORD=password -p 5433:5432 postgres:16 -c ssl=on -c ssl_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem -c ssl_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
```
docker run -d -e POSTGRES_PASSWORD=password -p 5433:5432 postgres:16 -c ssl=on -c ssl_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem -c ssl_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
```
docker run -d -e POSTGRES_PASSWORD=password -p 5433:5432 postgres:16 -c ssl=on -c ssl_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem -c ssl_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
)
Use
```
wrangler dev --remote
```
```
wrangler dev --remote
```
which spawns an ephemeral Worker and will behave like a normal Worker. Still wants a
```
localConnectionString
```
localConnectionString
```
localConnectionString
```
localConnectionString
but will use the Hyperdrive binding you give it instead.
Use a remote DB that allows connections with
```
sslmode=disable
```
sslmode=disable
```
sslmode=disable
```
sslmode=disable
(this is probably the hardest to mange given I don't think Supabase supports that)

Y

Yu•12/23/24, 4:29 PM

I have tried the third method, but supabase does not support it.

K

kchro3•12/24/24, 12:40 AM

Hey, are there any issues with Hyperdrive today? I've been getting 504s for the last half hour or so

A

AJROP•12/24/24, 12:52 AM

Let me take a look real quick

K

kchro3•12/24/24, 12:56 AM

Thank you! It looks like I'm getting connection timeouts to my RDS

A

AJROP•12/24/24, 12:57 AM

No, no changes in general behavior on our monitoring, no releases going out today or anything like that

K

kchro3•12/24/24, 12:57 AM

[wrangler:inf] GET ... 500 Internal Server Error (30722ms)
Error: write CONNECT_TIMEOUT ...:5432
    at RG (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:18734)
    at n (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:78:3715)
    at cachedError (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:6484)
    at new Query (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:4794)
    at Ve (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:88:1506)
    at getTemplateRules (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:769:3897) {
  code: CONNECT_TIMEOUT,
  errno: CONNECT_TIMEOUT,
  address: ...,
  port: 5432,
  stack: Error: write CONNECT_TIMEOUT .../.wrangler/tmp/dev-pvRk1H/index.js:769:3897)
  ...
}

[wrangler:inf] GET ... 500 Internal Server Error (30722ms)
Error: write CONNECT_TIMEOUT ...:5432
    at RG (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:18734)
    at n (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:78:3715)
    at cachedError (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:6484)
    at new Query (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:4794)
    at Ve (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:88:1506)
    at getTemplateRules (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:769:3897) {
  code: CONNECT_TIMEOUT,
  errno: CONNECT_TIMEOUT,
  address: ...,
  port: 5432,
  stack: Error: write CONNECT_TIMEOUT .../.wrangler/tmp/dev-pvRk1H/index.js:769:3897)
  ...
}

[wrangler:inf] GET ... 500 Internal Server Error (30722ms)
Error: write CONNECT_TIMEOUT ...:5432
    at RG (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:18734)
    at n (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:78:3715)
    at cachedError (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:6484)
    at new Query (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:4794)
    at Ve (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:88:1506)
    at getTemplateRules (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:769:3897) {
  code: CONNECT_TIMEOUT,
  errno: CONNECT_TIMEOUT,
  address: ...,
  port: 5432,
  stack: Error: write CONNECT_TIMEOUT .../.wrangler/tmp/dev-pvRk1H/index.js:769:3897)
  ...
}

[wrangler:inf] GET ... 500 Internal Server Error (30722ms)
Error: write CONNECT_TIMEOUT ...:5432
    at RG (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:18734)
    at n (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:78:3715)
    at cachedError (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:6484)
    at new Query (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:67:4794)
    at Ve (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:88:1506)
    at getTemplateRules (file:///Users//.wrangler/tmp/dev-pvRk1H/index.js:769:3897) {
  code: CONNECT_TIMEOUT,
  errno: CONNECT_TIMEOUT,
  address: ...,
  port: 5432,
  stack: Error: write CONNECT_TIMEOUT .../.wrangler/tmp/dev-pvRk1H/index.js:769:3897)
  ...
}

this is the error i'm seeing in my dev remote instance

A

AJROP•12/24/24, 12:58 AM

Hmmm. DM me your config if you wouldn't mind, and I'll take a look when I'm at my desk.

How regular? 1 in 100 requests? 1 in 100000?

K

kchro3•12/24/24, 12:59 AM

my wrangler toml?

K

kchro3•12/24/24, 1:00 AM

all requests look like they're failing

AAJR Couple options. * One is to have a local DB (I keep this alias in my bashrc: `...

Y

Yu•12/24/24, 6:14 AM

Use wrangler dev --remote, but can not connect the remote worker, it show the bug : Failed to unregister worker TypeError: fetch failed

P

plurk•12/27/24, 6:08 PM

I'm trying to make hyperdrive work in a svelte-kit project that uses drizzle. All the examples of hyperdrive usage I could find get

env

env

in the request, but in my project drizzle configuration is defined in a separate file:

const client = postgres(process.env.db || DATABASE_URL, {
  ssl: DATABASE_SSL === 'true',
  prepare: false
});

export const db = drizzle(client, { schema });

const client = postgres(process.env.db || DATABASE_URL, {
  ssl: DATABASE_SSL === 'true',
  prepare: false
});

export const db = drizzle(client, { schema });

const client = postgres(process.env.db || DATABASE_URL, {
  ssl: DATABASE_SSL === 'true',
  prepare: false
});

export const db = drizzle(client, { schema });

const client = postgres(process.env.db || DATABASE_URL, {
  ssl: DATABASE_SSL === 'true',
  prepare: false
});

export const db = drizzle(client, { schema });

I tried to use process.env, but got no luck here. Can anyone please suggest the proper way to pass the hyperdrive url?

Pplurk I'm trying to make hyperdrive work in a svelte-kit project that uses drizzle. Al...

I

Isaac McFadyen•12/28/24, 2:49 AM

You probably want to recreate the Drizzle instance every time. Something like this:

export const createDrizzle = (url: string, ssl: boolean) => {
    const db = postgres(url, {
        ssl
    });
    return drizzle(client, { schema });
};

export const createDrizzle = (url: string, ssl: boolean) => {
    const db = postgres(url, {
        ssl
    });
    return drizzle(client, { schema });
};

export const createDrizzle = (url: string, ssl: boolean) => {
    const db = postgres(url, {
        ssl
    });
    return drizzle(client, { schema });
};

export const createDrizzle = (url: string, ssl: boolean) => {
    const db = postgres(url, {
        ssl
    });
    return drizzle(client, { schema });
};

Then use

const db = createDrizzle(env.HYPERDRIVE_URL, env.SSL)

const db = createDrizzle(env.HYPERDRIVE_URL, env.SSL)

const db = createDrizzle(env.HYPERDRIVE_URL, env.SSL)

const db = createDrizzle(env.HYPERDRIVE_URL, env.SSL) where you need to use it.

This would normally be bad because it reconnects to the DB every createDrizzle call. But it's OK with Hyperdrive because Hyperdrive handles pooling for you.

I

Isaac McFadyen•12/28/24, 2:50 AM

Please correct me if I'm wrong on that AJR

A

AJROP•12/28/24, 2:50 AM

I'm not familiar enough with Drizzle to answer the original question, but can confirm you're right that the client connection is super fast and would be fine for Hyperdrive.

AAJR I'm not familiar enough with Drizzle to answer the original question, but can co...

I

Isaac McFadyen•12/28/24, 2:50 AM

Then yeah Drizzle itself is lightweight to create so as long as Hyperdrive is OK then it's good.

Pplurk I'm trying to make hyperdrive work in a svelte-kit project that uses drizzle. Al...

A

AJROP•12/28/24, 2:51 AM

Ah, also, wouldn't recommend

prepare: false

prepare: false

prepare: false

prepare: false. We've optimized a bit for the defaults postgres.js uses, so

prepare: true

prepare: true

prepare: true

prepare: true will generally be preferable. Especially if you have caching enabled.

A

AJROP•12/28/24, 2:52 AM

Not, like, a huge deal. But since you're in here asking.

I

Isak•12/29/24, 10:33 PM

It would be helpful if the full configuration names were displayed in the list of hyperdrives on the dashboard. Currently, they are truncated, making it difficult to distinguish between similar names.

I

Isak•12/29/24, 10:40 PM

Would it also be possible to configure the cache on a per-query basis? Some queries can be cached indefinitely, while others require fresh data every time.

IIsak Would it also be possible to configure the cache on a per-query basis? Some quer...

A

AJROP•12/30/24, 3:33 AM

This is something that we're actively exploring, it's been a regular request. The challenge is finding a good UX for indicating to Hyperdrive that a query should or should not be cached. We try pretty hard to support as wide an array of ORMs as can use our supported drivers. The various ways they do/don't bundle information into their queries means that a lot of the obvious ways of doing this wouldn't work on various subsets of them.

AAJR This is something that we're actively exploring, it's been a regular request. ...

I

Isak•12/30/24, 5:14 AM

I understand there’s a lot to consider, and I’m looking forward to seeing this shipped in the future.

A

arfath_linklet•12/31/24, 5:01 AM

We're testing out latencies before we can go all-in on cloudflare workers. Considering a single request may have multiple hops between db and worker the latencies are not acceptable when distributing globally. We've kept smart placement on to try and force it to keep it closer to the db but it's been days and multiple requests and we're still seeing local placement. Given that we can't reliably place and predict our workers, it's hard to justify this lock-in. Would the team be able to share how we can reliably hint / enforce smart placement to kick in?

In terms of how you'd actually use them, if you wanted to port away, no not really. You have the op

Similar Threads

Similar Threads

Similar Threads