I'm not familiar enough with Drizzle to answer the original question, but can confirm you're right t

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

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

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

Ah, also, wouldn't recommend

prepare: false

prepare: false

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

prepare: true

prepare: true

will generally be preferable. Especially if you have caching enabled.

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

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

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.

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

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

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.

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?

Aarfath_linklet We're testing out latencies before we can go all-in on cloudflare workers. Consi...

AJROP•12/31/24, 2:08 PM

There's a few moving parts here. Please DM me and we'll get you sorted out.

AJROP•12/31/24, 2:10 PM

Public answer in case it's useful for others:

Disabled caching will help smart placement (though obviously at the cost of having caching, so it depends on your workload which is better for you)
We have some manual tweaks we can do to help with placement, on request. We're working on automating these steps such that they'll happen for all Hyperdrives without our intervention, that work is in progress.

AAJR There's a few moving parts here. Please DM me and we'll get you sorted out.

arfath_linklet•12/31/24, 2:31 PM

Will reach out! Thanks.

Mario Alberto•1/1/25, 8:11 PM

Hey

Huxwell | Reown•1/2/25, 10:03 AM

Hey team happy new year

I'm trying to figure out the optimal configuration for my worker using postgres.js, Hyperdrive and Supabase.

The first question I have is, what would be the ideal app side connection pool value https://github.com/porsager/postgres?tab=readme-ov-file#the-connection-pool ? ofc it depends on the application but if there's not much concurrent DB queries, I'm guessing the lower the better ? (default is 10 btw)
Regarding the connection string for Hyperdrive, should I use the direct DB connection string to the Postgres instance (current instance provides us 380 max direct client connections and we have 2 Hyperdrive instances connecting to it, one read only with cache and the other for writes and reads without cache). Would that be enough and how could we estimate the maximum client connections when using Hyperdrive ?
Supabase also offers a connection pooler (Supavisor), is there any drawback of using Hypderdrive in combination with Supavisor (1,500 connections included in our current plan). However when using Supavisor in transaction mode (port 6543) we must disable prepared statements and I think that session mode isn't advised in Serverless environments. What would be your suggestion here if applicable ?

We have quite a lot of traffic on our API and we also have special community events that trigger traffic spikes in short periods, eg 1M+ users running multiple requests at the same time. I'm currently doing some load testing which should help me to find the sweat spot but would appreciate your opinion. Thanks in advance.

GitHub

GitHub - porsager/postgres: Postgres.js - The Fastest full featured...

Postgres.js - The Fastest full featured PostgreSQL client for Node.js, Deno, Bun and CloudFlare - porsager/postgres

HHuxwell | Reown Hey team happy new year 🎉 I'm trying to figure out the optimal configuration ...

AJROP•1/2/25, 2:53 PM

Hello, and happy new year!

The default should be fine for you, it's what we test with most and shouldn't make a ton of difference if there's not a ton of app-level concurrency
Re: using Supavisor vs direct-to-DB connections -- we have seen some folks have issues using Supavisor in transaction mode (the prepared statements issues mostly), so we do not recommend using it with Hyperdrive. We do support prepared statements, and postgres.js uses them quite a lot, so generally we suggest a straight-to-db connection and letting Hyperdrive handle the pooling.
Re: expected connection counts -- we currently cap at 20 per region, so 80-100 total per Hyperdrive.
Re: throughput -- it's going to depend on your query patterns, generally. The mode by which Hyperdrive starts to cap out on throughput is connection exhaustion, so anything that causes connections to be held for longer is going to reduce your throughput. The worst offenders are heavy transactions (can't release a connection back to the pool until a transaction commits or rolls back, obviously), and slow queries (either due to DB CPU time or poor network connectivity to origin).
If you're seriously expecting heavier traffic than what you can comfortably succeed with during your load tests, DM me and let's see what we can do for you. We'll need to ask some questions about your usage to understand how best to help. I am certain @thomasgauvin would be up for scheduling a call to collect some details and discuss.

Huxwell | Reown•1/2/25, 3:46 PM

Thanks for the reply, happy to jump on a call whenever works best for you!

sam•1/2/25, 6:26 PM

happy new year!! i remember there being a release a few weeks ago that aimed to increase the number of colo's with a local hyperdrive cache (giving zero network-hop cache hits), but it was rolled back temporarily

is there a rough timeline for when we expect this to go out again? or still TBD depending on the investigation? thx for any info

(edit: have an email thread open with y'all already, just pinged here in case useful info for others in the community)

AJROP•1/2/25, 7:50 PM

We have the fix in place, going to start rolling it out next week. We decided that a change of that scope over the holidays would be unwise.

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

thomasgauvin•1/6/25, 5:23 PM

@Yu can you share more details on the error logs for option 2? It's the one that is the easiest to use

wrangler dev --remote

wrangler dev --remote

dave•1/6/25, 8:21 PM

Does Hyperdrive clear cached queries when inserting?

Ddave Does Hyperdrive clear cached queries when inserting?

AJROP•1/6/25, 8:27 PM

No, right now the cache is strictly TTL-based.

AAJR No, right now the cache is strictly TTL-based.

dave•1/6/25, 9:22 PM

Ouch, is there a way to clear it myself yet?

Ddave Ouch, is there a way to clear it myself yet?

AJROP•1/6/25, 9:24 PM

No. You can cache-bust individual queries by including any volatile function in them (e.g.

SELECT random(), * FROM mytable

SELECT random(), * FROM mytable

) but actual cache purge is still on our roadmap.

dave•1/7/25, 12:39 AM

Is Hyperdrive (during local dev) known to leak connections?

dave•1/7/25, 12:39 AM

Not sure if it’s me, Hyperdrive, or Google Cloud SQL Auth proxy to blame.

Ddave Is Hyperdrive (during local dev) known to leak connections?

AJROP•1/7/25, 2:56 PM

No, that is not a known issue.

We do rely on the Postgres server closing connections when they disconnect. If some other component is holding them open after we disconnect, then it's possible you would see that behavior.

AJROP•1/7/25, 2:57 PM

We do hold them open idle for 15 minutes, to prevent the overhead of having to spin up a new one after brief periods of inactivity.

Ssam happy new year!! i remember there being a release a few weeks ago that aimed to ...

AJROP•1/7/25, 6:33 PM

Just to close the loop, this is now released. Cheers, all.

Maraciuca•1/12/25, 8:54 PM

hiya, im desperately trying to understand how to use drizzle, hyperdrive and nextjs on edge but i swear im not getting past the env.HYPERDRIVE.connectionString step

has anyone dealt with some like this before?

dave•1/13/25, 4:44 PM

Should I be using

ctx.waitUntil(sql.end());

ctx.waitUntil(sql.end());

when I'm using Hyperdrive, or should I never use

sql.end()

sql.end()

Ddave Should I be using `ctx.waitUntil(sql.end());` when I'm using Hyperdrive, or shou...

Isaac McFadyen•1/13/25, 4:46 PM

I think it would depend on how you're connecting? Are you making a connection for each Worker request (new client in the

fetch

fetch

each time)?

Isaac McFadyen•1/13/25, 4:46 PM

If so then likely, but if you're using some sort of global/persistent connection then probably not.

IIsaac McFadyen If so then likely, but if you're using some sort of global/persistent connection...

dave•1/13/25, 4:46 PM

This is what I'm thinking of doing, putting the session in the global scope..

dave•1/13/25, 4:46 PM

not sure if it's a good idea

Ddave not sure if it's a good idea

Isaac McFadyen•1/13/25, 4:47 PM

I've heard mixed things. I think it's probably fine for a new client per request since Hyperdrive is very fast to connect.

Isaac McFadyen•1/13/25, 4:47 PM

Confirmed by an engineer here: https://canary.discord.com/channels/595317990191398933/1150557986239021106/1322396253832609835

IIsaac McFadyen I've heard mixed things. I think it's probably fine for a new client per request...

dave•1/13/25, 4:50 PM

so it's not reopening connections on the backend?

Ddave so it's not reopening connections on the backend?

Isaac McFadyen•1/13/25, 4:53 PM

It re-opens connections to Hyperdrive, but Hyperdrive is a Durable Object running near your Worker so that's quite fast. Hyperdrive itself holds open connections even if you call

sql.end()

sql.end()

so you should be good.

dave•1/13/25, 5:07 PM

sweet, thanks!

AJROP•1/13/25, 6:12 PM

All correct, yep. Not actually a DO, though. It runs as a separate service on our servers.

dave•1/13/25, 6:27 PM

In my Worker client, am I restricted to 6 max connections per instance?

Ddave In my Worker client, am I restricted to 6 max connections per instance?

Isaac McFadyen•1/13/25, 6:40 PM

Yes. All of the Postgres drivers (with the exception of like Neon WebSockets or certain non-Hyperdrive) connect via TCP which is subject to the 6 connection limit.

IIsaac McFadyen Yes. All of the Postgres drivers (with the exception of like Neon WebSockets or ...

dave•1/13/25, 6:50 PM

Ooo that’s good to know! So I should limit postgres.js to like 5 connections to be safe? (To avoid deadlocking unrelated http requests.)

Ddave Ooo that’s good to know! So I should limit postgres.js to like 5 connections to ...

Isaac McFadyen•1/13/25, 6:55 PM

I'd tentatively say yes unless hyperdrive has an exception applied within the runtime but I presume they do not. @AJR could confirm.

AJROP•1/13/25, 6:59 PM

Hyperdrive does not have any exceptions in that way, same 6 connection limit applies here. If you're concerned you might want to set that limit on your postgres.js connection, yes.

dave•1/13/25, 7:12 PM

Do PostgreSQL channels work with hyperdrive?

dave•1/13/25, 7:13 PM

This stuff.

AJROP•1/13/25, 7:15 PM

No, I'm afraid not. It's something I've poked at a little, but it's not likely to get added any time soon, unfortunately.

We document a bit of this here, if it's helpful: https://developers.cloudflare.com/hyperdrive/configuration/how-hyperdrive-works/#unsupported-postgresql-features

Cloudflare Docs

How Hyperdrive works · Hyperdrive

Connecting to traditional centralized databases from Cloudflare's global network which consists of over 300 data center locations

presents a few challenges as queries can originate from any of these locations.

AAJR No, I'm afraid not. It's something I've poked at a little, but it's not likely ...

dave•1/13/25, 7:56 PM

ah thank you, I was walking while trying to find that page

Does .execute and .cancel work with Hyperdrive? It's working locally, so not sure if that's a good sign or not. https://github.com/porsager/postgres?tab=readme-ov-file#execute

AJROP•1/13/25, 8:03 PM

.execute()

.execute()

does (I believe, that's a Postgres.js internals thing but reading through it there's nothing about what it's doing that shouldn't, it's just firing off an

Execute

Execute

postgres message early, which we support).

.cancel()

.cancel()

does not, Hyperdrive is not able to support query cancellation.

AAJR `.execute()` does (I believe, that's a Postgres.js internals thing but reading t...

dave•1/13/25, 8:49 PM

If I do a .cancel(), will an error be thown?

I'm not familiar enough with Drizzle to answer the original question, but can confirm you're right t

Similar Threads

Similar Threads

Similar Threads