are there any recommendations on how to update hyperdrive if you want to rotate db passwords?
are there any recommendations on how to update hyperdrive if you want to rotate db passwords?
ACloudflare Docs
You can change the connection information and credentials of your Hyperdrive configuration in one of two ways:
W@Hyperdrive ^
I@Nick I remember you asking about this before ^
AI think Neon's doc says they do not recommend using Neon's pool with Hyperdrive, which is aligned with Hyperdrive's doc.
JYup using hyperdrive with direct connection to Neon, got set up in like 10 minutes and working great 
XHello
H@Walshy
I?pings
SPlease do not ping community members for non-moderation reasons. Doing so will not solve your issue faster and will make people less likely to want to help you.
Mdoes hyperdrive over cloudflared tunnel require dns records?
Mno wait, it seems to want SSL. shouldn't the tunnel already be encrypting traffic?
Mcan i use self-signed certs? connection still failing
Mvery little info being provided from the web ui just says 403 forbidden
Mcant see any activity in the 2 cloudflared instance logs
Mversion of cloudflared is
2024.9.1what the heck is going on. this is the tunnel configuration
ive confirmed multiple boxes in the cluster can access via psql, and im still not seeing anything in the cloudflared logs
ive confirmed multiple boxes in the cluster can access via psql, and im still not seeing anything in the cloudflared logs
Mnone of this has worked:
- enable SSL on postgres
- disable TLS verification for tunnel backend due to self-signed cert
- upgrade version of cloudflared to
2025.2.1
ARun the tunnel with loglevel=debug to see individual connection attempts and responses.
A403 is usually an Access refusal. Check the logs on your access policy too? For service tokens you'll need to query them via API, the tunnel dash doesn't show service access login attempts
AYes it does
AShould be fine with this version
MI had to abandon hyperdrive, I noticed you're limited to 25 db connections which bundles auth and my per-user auth reaches to the db so i'd quickly hit the 25 limit
Mone thought i had while i was prototyping is that it shouldn't require public DNS records
load balancer works without them and provides much more security by not exposing your db endpoint publically
load balancer works without them and provides much more security by not exposing your db endpoint publically
Mthere probably needs to a bigger push to allow any cloudflare service to connect to tunnels without having them exposed publically
AThis is something we're tinkering with. The trick is to still take advantage of Access for security without a hostname.
AHyperdrive is a transaction mode pooler, so those 25 go a lot further than you might imagine. Also the default limit is 60 after last month, with plans to make it adjustable down the road a bit.
Not saying you should reconsider, but just stating for posterity
Not saying you should reconsider, but just stating for posterity
KHi, I am seeing a ton of logs like this:
Error: write CONNECTION_CLOSED <...>.hyperdrive.local:5432
can someone explain what this does
Error: write CONNECTION_CLOSED <...>.hyperdrive.local:5432
can someone explain what this does
Kwe had as high as 20 errors per second and a couple hundred failures over a 10 min period
K
Bi am using neon. i use neon branches for local development. when i set my neon branch connection string in .dev.vars (WRANGLER_HYPERDRIVE_LOCAL_CONNECTIONSTRING<BINDING>=neon branch connection string) and run wrangler dev. it recognizes my environment variable
now when i get the connection string from the binding (BINDING.connectionString), it returns a
what am i doing wrong?
Found a non-empty WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING variable for binding. Hyperdrive will connect to this database during local development.now when i get the connection string from the binding (BINDING.connectionString), it returns a
hyperdrive.localwhat am i doing wrong?
Khas there been an uptick in the number of these
I've been getting tons of these starting yesterday, and even though I've added retry logic, it's still concerning & a waste of CPU time
Error: write CONNECTION_CLOSED <...>.hyperdrive.local:5432I've been getting tons of these starting yesterday, and even though I've added retry logic, it's still concerning & a waste of CPU time
AThere was an accelerated release yesterday that may have severed some connections. We'll need to investigate that, there shouldn't have been the level of disruption you're describing.
Are you still observing elevated error rates? I'm not seeing any such in our broader monitoring.
Are you still observing elevated error rates? I'm not seeing any such in our broader monitoring.
Kyup, here's our 24hr view
Kwe haven't made any significant code changes before we started seeing errors, except to add retries
AI think you were working with Adrian? Let me touch base with him
Kyes, thank you
Kstill seeing this error... please let me know if there are things that I can try as mitigations or if there are any updates
for now, i'm trying to see what'll happen if i disable hyperdrive caching since i have a separate cache in front of my postgres client
for now, i'm trying to see what'll happen if i disable hyperdrive caching since i have a separate cache in front of my postgres client
AWe're investigating internally. We will share updates as we have them.
IWe are also seeing increased CONNECTION CLOSED errors, although also are dealing with increased traffic so hard to tell if its the same % or not
Asame ID as in our thread?
AWent looking. I do see a bump in disconnects for you, but it's not related to what kchro3 is dealing with.
FHey everyone, I'm testing hyperdrive. These are my results:
/api/test/ ---> 200ms first hit, 3-7ms subsequent calls. Great!
/api/test/:id ---> 200-600ms always.
I see in the Hyperdrive analytics that I have a lot of "Uncacheable" requests. I guess this is the dynamic endpoint.
I'm trying to understand why or how it works? Is there a workaround? Does hyperdrive always relay on caching? I'm wondering for the stale data too.
Thanks!
/api/test/ ---> 200ms first hit, 3-7ms subsequent calls. Great!
/api/test/:id ---> 200-600ms always.
I see in the Hyperdrive analytics that I have a lot of "Uncacheable" requests. I guess this is the dynamic endpoint.
I'm trying to understand why or how it works? Is there a workaround? Does hyperdrive always relay on caching? I'm wondering for the stale data too.
Thanks!
SOnly static SELECT queries qualify for caching.
FThanks. 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)
