How does it determine which replica to use by default?
How does it determine which replica to use by default?
Dthe first one is used for any mutations, and the rest (second param) are for read-only queries
HSo the read replicas are just chosen randomly?
Ssorry for the noob question, just now reading into hyperdrive, and it looks really nice ---
if I am building an API on CF workers, and want to use hyperdrive, would I need another worker to be the proxy and connect drizzle to the other worker, or could it all be done in one worker without exposing a query endpoint?
if I am building an API on CF workers, and want to use hyperdrive, would I need another worker to be the proxy and connect drizzle to the other worker, or could it all be done in one worker without exposing a query endpoint?
AYou can query the DB via hyperdrive via any worker. No need for a proxy.
EHi @AJR, I saw in the Hyperdrive Changelog https://developers.cloudflare.com/hyperdrive/platform/changelog/#2024-05-22 that there were some driver performance improvements for postgres.js. However, I’m testing a hyperdrive connection using a worker and am finding that with caching enabled and
{ "prepare": true } I get 100% cache misses on a simple SELECT like const [user]: [User?] = await sql`SELECT * FROM users WHERE id = ${userId};. If I set { “prepare”: false } then latency improves, I get some cache hits but the majority are marked as uncacheable on the same repeated query. Any help is greatly appreciated, (happy to DM my connection id) - thanks.Cloudflare Docs
You can now create up to 25 Hyperdrive configurations per account, up from the previous maximum of 10.
TI have some Cloudflare Pages apps that needs to access a Postgres DB. I also have traditional workloads that connects to Postgres, which lives right next to the Postgres box.
Is it better to connect everything through Hyperdrive or should the traditional workload also be routed through Hyperdrive? And if I should keep the traditional workloads connecting directly to Postgres, how should I set up pgBouncer so that I don't run out of connections - should Hyperdrive connect to pgBouncer, or to Postgres directly?
Is it better to connect everything through Hyperdrive or should the traditional workload also be routed through Hyperdrive? And if I should keep the traditional workloads connecting directly to Postgres, how should I set up pgBouncer so that I don't run out of connections - should Hyperdrive connect to pgBouncer, or to Postgres directly?
AIn that architecture, traditional workloads should probably not go through Hyperdrive.
Our general recommendation is that Hyperdrive should connect directly, as stacking multiple poolers on top of each other usually has no benefit and can cause issues in some cases. That said, I know many users do connect Hyperdrive to another pooler and it works fine for them. Your use case is unique enough that having everything centrally run through pgbouncer might be warranted. You'd need to do some testing to see how well either arrangement works.
Our general recommendation is that Hyperdrive should connect directly, as stacking multiple poolers on top of each other usually has no benefit and can cause issues in some cases. That said, I know many users do connect Hyperdrive to another pooler and it works fine for them. Your use case is unique enough that having everything centrally run through pgbouncer might be warranted. You'd need to do some testing to see how well either arrangement works.
A- It's a simple TTL cache. Once a request is cached, Hyperdrive will attempt to serve from cache until the cached result expires. It does not do any proactive purging on mutation.
- Same as 1. If you really need to bypass cache on individual queries, current best option is include any volatile function in your query (e.g. including
random()in your SELECT statement). Offering a better option for this is on our radar but not for very soon. - Latency will still be much better through Hyperdrive than a direct connection in most cases (with the caveat that networking is a dynamic thing and sometimes routes can get weird). However cache hits will always be much faster than anything else, so it's up to you what tradeoffs are right for your use case.
APlanned, but not for very soon. Got a few big features we've promised to deliver on first.
Psomehow we've started hitting cache a wee bit!
PI assume you did something on the backend, thank you!
JI'm not able to create new Hyperdrive configs or update the existing ones via the CF Dashboard and wrangler on the terminal on an account with a paid plan. I was able to create before. I'm getting this error:
I did try logging out then re-logging in.
I did try logging out then re-logging in.
ALet me check in on this.
A@jared give it a shot now.
JI was already able to update the existing configs. Thank you.
ACurrently our top priority and will be our next big feature released. See hyperdriveWhile waiting for Cloudflare Tunnel for a bit more discussion.
AWill this adress the issue of Hyperdrive placement in APAC region?
AThat's a separate track of work and is coming along soon. That's not a feature it's a fix, sorry for the confusion there.
AThough, that raises a good point. If your setup is in APAC and you're having latency issues, please message me directly.
P@AJR have your team done performance work with Hyperdrive under the hood in the past two weeks?
P
PI'm in the US east again and this is my latency now
P2x improvement
Psame location
Poop, sorry, here are the correct numbers
Pso from 620-770ms to 360-520
P(still not as fast as a VPN to europe but incredible improvement in such a short time!)
PYeah
PUS East → hetzner germany
Pah, I was so excited... well i'm still excited but
PI was about to be like "wow wtf did you change to save 200ms"
Plmk if I can beta test it in the future, sounds very exciting to me
JHi! In which regions/colos can Hyperdrive spawn? And is there any way to know in which location i'm currently connected?
THi João! Hyperdrive can spawn in various regions, usually one that's closest to your Worker making the request, and no, there's no way to know which region it's spawned in
I^ to add to this, Hyperdrive is always spawned in a region with a DO but may not spawn in every DO region (I'm uncertain, only someone on the Hyperdrive team would know). But you can certainly use the non-DO regions as an indicator of where it does not spawn. Here's a community-sourced tool for exploring DO regions: https://where.durableobjects.live/
Tracking where Durable Objects are created, wherever you are in the world.
JIt seems like sometimes the EU Hyperdrive pool for our DB is going unavailable for a few minutes and then coming back online. Could someone take a look at this? Thanks!
Account ID: 978f7d8fe0d7c314743586a46e505f14
Account ID: 978f7d8fe0d7c314743586a46e505f14
JWhile testing we noticed that having a worker close to London try to connect would result in an error, but in other regions it would run properly
Ehello and good day!
im trying to understand. Every other day HyperDrive fails for me for about 1 hour...
and then comes back.
like right now is failing : error: Failed to acquire a connection from the pool.
and there is nothing i can do because i know its not my side, because i can connect directly to the DB. (Yes, this could be a solution, trying to monitor these error and switch to direct connection)
but i think i should be able to work with hyperdrive.
im trying to understand. Every other day HyperDrive fails for me for about 1 hour...
and then comes back.
like right now is failing : error: Failed to acquire a connection from the pool.
and there is nothing i can do because i know its not my side, because i can connect directly to the DB. (Yes, this could be a solution, trying to monitor these error and switch to direct connection)
but i think i should be able to work with hyperdrive.
Eis anyone else experiencing this?
Ei dont even do that many things.... but was hoping to do in the future...
Ethere is the timeouts....
