PYes
Pis that my issue?
AIt's wrapping everything in explicit transactions, which disables caching
Pcan I disable that?
AThat I'm not sure of. We don't cache queries that are part of transactions (though in theory we could get at least some of them safely)
Pits interesting, usually I see
begin and commit in my logs when I'm doing a transaction
AI imagine there's probably a way to do so? ORMs tend to add extra magic like this, but each one has its own settings.
Pis it wrapping each query in a transaction that is somehow bypassing
begin and commit and doing it on a protocol level?AI'm seeing commits
AOne sec, let me dig a bit further
Pthere are some transactions I make explicitly
Ppost, put, patch and delete requests exclusively
AOk, I do see some queries that I'd have expected to be cached that are getting marked "uncacheable", and it's not immediately clear to me why. I'm going to open a ticket for this, since as far as I can tell those should be cooperating. It's probably going to be a bit before I can get to this, but we'll sort it out. If it's affecting you there'll be other users too. Worst case I at least turn up a definitive explanation.
PThank you so much!
ANo 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 }const [user]: [User?] = await sql`SELECT * FROM users WHERE id = ${userId}{ “prepare”: false }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
in your SELECT statement). Offering a better option for this is on our radar but not for very soon.random() - 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!
