Thanks. Do you think the 200ms latency is due to me being in Brasil and the DB in Germany?
Thanks. Do you think the 200ms latency is due to me being in Brasil and the DB in Germany?
SYes for sure.
FThanks. Just tested it with a VPN and yes 
SI think smart placement would be something usefull to look at. Saves time in roundtrips in your code
FI was going to ask you that. I have it in smart placement, but it seems like the worker is processed close to the end-user (in this case, me)
SYou'll need more requests to have it kick in then
FInteresting. So when you have a lot of requests it will process the request close to the db?
SYes it needs to analyse your requests: https://developers.cloudflare.com/workers/configuration/smart-placement/#understand-how-smart-placement-works
SAh wait nvm, it does not apply to Hyperdrive. Sorry
FDamn. Would be nice if we could set a base region and maybe some replicas if needed
AIt actually does apply to Hyperdrive
APart of the benefit of the recent pool placement work is that it'll play way nicer with smart placement
AActually we can cache extended protocol queries too, but each different ID in this case will be a cache miss the first time you see it
AIf you re run with the same ID and are seeing misses I'd be curious to poke a bit more. Probably there's something odd with your connection settings that is causing issues for caching. First guess would be a prepare: false setting
FOkay, cool! I will check it later if this is an issue with my settings or code
AFeel free to DM me with specific queries and connections settings and such. Happy to dig a bit, this is a complicated part and it's always useful to me to see how exactly folks are using it
FThanks, I appreciate it
JHello, seeing a lot of
Connection terminated unexpectedly errors suddenly, how can I debug?
Aplease post or DM your hyperdrive ID.
TWe made it official with an announcement 
: https://developers.cloudflare.com/changelog/2025-03-04-hyperdrive-pooling-near-database-and-ip-range-egress/
TLDR:
: https://developers.cloudflare.com/changelog/2025-03-04-hyperdrive-pooling-near-database-and-ip-range-egress/TLDR:
- Query latency is reduced by 90% (!) by pooling databases connections closer to your database (as mentioned by @AJR earlier this week)
- Hyperdrive uses Cloudflare IP addresses to connect to your database so you can configure access control lists on your database firewall (as mentioned by @xortive earlier this week)
- Workers Smart Placement is more effective with Hyperdrive to ensure minimal network latency for db queries
RThe link in the changelog is
https://developers.cloudflare.com/hyperdrive/platform/changelog/(https://www.cloudflare.com/ips/RJust a malfunctioned link
Dkinda interesting, it seems like my hyperdrive performance has gotten significantly worse in last 24 hours
D
Dconnection latency in last 6 hours is 100ms
Dvs 34ms over last week
AMind sending me the ID? We haven't released any changes in the last 24 hours, I'd be curious to see where you're at.
DIMO the firewall news so great I wish it was an email! I was very happy to see that news in my RSS feed.
Mhas anyone used for pushing data onto a kafka queue?
Mor anything similar (redpanda, celery, some other db etc.)?
Dimo I found traditional queues to be more complicated than needed. I personally recommend just using PostgreSQL and polling a table with a Cron Worker.
MI agree, but I want to keep some high volume financial data in a backup server (apart from D1), and was wondering if I can push that onto a kafka which later can be processed by something else (aws rds probably).
AFolks internally have absolutely used a Cloudflare Queue as part of their architecture, where it eventually lands into an RDBMS. You can't talk to Hyperdrive directly from a queue but you can definitely stick a worker on the end and from there bulk load that data into your DB.
DI'm curious as to why the docs for postgres.js say
max: 5 instead of max: 1 for connections? https://developers.cloudflare.com/hyperdrive/configuration/connect-to-postgres/#postgresjsCloudflare Docs
Hyperdrive supports PostgreSQL and PostgreSQL-compatible databases, popular drivers and Object Relational Mapper (ORM) libraries that use those drivers.
AWorkers allow a limit of 6 concurrent outgoing connections. If you run into that it can cause some hard-to-debug error scenarios. That's the main concern for that setting, which was my focus when adding that note. If you don't want multiple concurrent queries,
max: 1 is probably better as it's fewer moving parts to debug if you do run into issues.
AThere's an open issue to set the default to something safer for Workers, but I'm not sure how that's going to play out: https://github.com/porsager/postgres/issues/1023
GitHub
With the following Cloudflare Worker, errors can be observed when deployed to production: import postgres from 'postgres'; export default { async fetch(request, env, ctx): Promise<Respon...
DIs there likely any noticeable difference between 1 and 5?
DInteresting, why are you limited to just 60? (Not an issue for me yet in my use-cases.)
I thought Hyperdrive would be able to handle a near infinite number of connections from Workers.
I thought Hyperdrive would be able to handle a near infinite number of connections from Workers.
Dai.moda
Learn how to automatically manage rotating credentials and AWS IAM tokens for PostgreSQL databases using Cloudflare Workers and Hyperdrive.
DMonthly ping to let the team know I would be willing to pay for this. (Which is saying a lot, since I’m famously a freeloader when it comes to cloud services.)
DOh, I think I have run into this actually.. does this translate to about 60 concurrent Workers then? Or more?
ASubstantially more. We see folks up past 1k QPS with this right now, glancing at logs at the moment.
ACouple reasons.
Connections do use memory and CPU and those aren't free, even for us.
Given that it's not self service to change it, if we pick a value that's too high Hyperdrive will just knock over free tier offerings from most providers. When we do make this self service we'll allow a higher maximum value to be set.
If folks hit this limit (or expect to) and reach out to us, we can set it higher manually for them for now. Many customers have. It's a good forcing function for us not to put off the self-service work for too long.
At some point we'll probably allow an absurdly high value to be set with some sort of billing implication, such that we can recoup the cost of resources if people really want to blow the doors off something. We've got some internal teams using Hyperdrive for their products set as high as 1500.
Connections do use memory and CPU and those aren't free, even for us.
Given that it's not self service to change it, if we pick a value that's too high Hyperdrive will just knock over free tier offerings from most providers. When we do make this self service we'll allow a higher maximum value to be set.
If folks hit this limit (or expect to) and reach out to us, we can set it higher manually for them for now. Many customers have. It's a good forcing function for us not to put off the self-service work for too long.
At some point we'll probably allow an absurdly high value to be set with some sort of billing implication, such that we can recoup the cost of resources if people really want to blow the doors off something. We've got some internal teams using Hyperdrive for their products set as high as 1500.
AThis one is hard for me to answer, as someone who spends more time in C or Rust than in JavaScript.
Each of those really is a separate connection, so if you do actually want to have multiple queries going at the same time than I think probably there is a difference, yes.
But on Workers I think the general design philosophy would be to do more Workers, not more stuff within a Worker, so I'm not sure how often that would come up in practice.
Each of those really is a separate connection, so if you do actually want to have multiple queries going at the same time than I think probably there is a difference, yes.
But on Workers I think the general design philosophy would be to do more Workers, not more stuff within a Worker, so I'm not sure how often that would come up in practice.
A@thomasgauvin one for your list. Not sure what info you need.
Beta isn't running yet, but should be pretty soon.
Beta isn't running yet, but should be pretty soon.
Sanyone know off the top of their head what the best way to timeout a hyperdrive query using postgres.js?
we setup the client with these opts
my understanding is that the wall clock in cf workers will only advance when there is external io performed, so setTimeout will often but not always enforce the timeout? (our metrics confirm this, but just making sure i understand why)
maybe just need to add a max_lifetime or idle_timeout to the connection options instead?
(pics are in US-mountain tz, with the cf dashboard showing avg query latency spiking around the same time as we were seeing internal metrics for max latencies higher than all the timeouts we have set in code)
we setup the client with these opts
{ connect_timeout: 1, max: 5 } and also have some setTimeout( helpers wrapping the whole function issuing the query -- but still see some successful queries record latencies of multiple minutes sometimesmy understanding is that the wall clock in cf workers will only advance when there is external io performed, so setTimeout will often but not always enforce the timeout? (our metrics confirm this, but just making sure i understand why)
maybe just need to add a max_lifetime or idle_timeout to the connection options instead?
(pics are in US-mountain tz, with the cf dashboard showing avg query latency spiking around the same time as we were seeing internal metrics for max latencies higher than all the timeouts we have set in code)
ASorry, not sure I'm following.
I would describe the use case of Hyperdrive as: "I, as a user, want to make a fullstack application on Workers, with my database hosted on Postgres somewhere. I will accomplish this by writing a Worker script that uses a standard Javascript Postgres driver/ORM to query my database".
Websockets can certainly play into some architectures depending on your use case, but I'd imagine most of our users do not use them.
I would describe the use case of Hyperdrive as: "I, as a user, want to make a fullstack application on Workers, with my database hosted on Postgres somewhere. I will accomplish this by writing a Worker script that uses a standard Javascript Postgres driver/ORM to query my database".
Websockets can certainly play into some architectures depending on your use case, but I'd imagine most of our users do not use them.
AIt will be handled automatically. There are two different "types" of connections at play here. The Hyperdrive->Origin connections are limited, and automatically managed. You shouldn't need to do anything to manage those except not leave a transaction open forever (which breaks Postgres anyway so probably don't do that). Whenever a query completes that connection is put back into the pool for other queries to use. The phrase to search for to learn more would be "transaction-mode connection pooler"
The Worker->Hyperdrive connections can be left open, and are not limited. That's what you'd be leaving sitting open with the architecture you're describing. That should work fine. There's a 15-second timeout on those if they're idle, so if you're going to have low traffic you may want to have a "re-open my connection" control flow path, I guess?
The Worker->Hyperdrive connections can be left open, and are not limited. That's what you'd be leaving sitting open with the architecture you're describing. That should work fine. There's a 15-second timeout on those if they're idle, so if you're going to have low traffic you may want to have a "re-open my connection" control flow path, I guess?