No problem. Again, I appreciate you taking the time to write stuff up as you go. It helps us a lot
No problem. Again, I appreciate you taking the time to write stuff up as you go. It helps us a lot.
PAlso, thinking about it, cf boston is magically adding ~280-300 of latency might be not surprising if your numbers are 100ms of cache miss (overhead, I assume?), plus of course the 50ms to actually handle it, so that is 130ms of ??? which is less surprising. I assume
- There's not any ideas of what could be done on your end (eg. its your isp or whatever)
- My best course of action is trying another cloud provider
PI appreciate you being so attentive, its very rare to have this sort of discourse where the person on the other end is both directly involved with the product and actively engaged with users. Keep it up, you rock
AThat 100ms for cache miss isn't overhead, it's the total time we usually see. It's not quite "total" as there's still some transit after it leaves our network, but we try to have that number be as complete as we can.
Pso then I really am curious where the 250-300 is coming from
PI mean what would the difference be between localhost → remote db and cloudflare → remote db?
AMe too. The fact that it's still there on non-hyperdrive traffic takes it out of my hands a bit, but I'd be curious to know.
Poh right, that would indicate its a network thing and not a you thing
Phadn't made that connection
Pmakes sense
Pill give aws a go
PStill traveling so no laptop but it’s very fast
PGod bless monitoring…. 90ms for the db round trip and likely another 50ms of overhead in total, so we’ll say 150ms
POne future hyperdrive feature of interest might be supporting replicated databases. You might be able to do this by setting up multiple hyperdrive bindings and switching yourself?
PCuz yeah sub 200ms would be slick
PBro what
P
PGyahhh
PI think if everyone in the world got latency this low we might achieve world peace
PHopefully ec2 in the EU can provide this for Americans 
, at least until we get a replication story going
, at least until we get a replication story goingAI know some users have configured multiple hyperdrives to roll their own for now, but it's definitely a gap we're aware of.
Glad to see it cooperating for you!
Glad to see it cooperating for you!
Dyup, we're one of those users, with drizzle it's quite easy: https://orm.drizzle.team/docs/read-replicas
Drizzle ORM is a lightweight and performant TypeScript ORM with developer experience in mind.
HHow 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
