Hyperdrive is only for Workers. It will say active if it’s received queries recently
Hyperdrive is only for Workers. It will say active if it’s received queries recently
PThank you. It won't work for my use case then.
Zif i want to use hyperdrive+tunnel to access a private db in google cloud sql, do i need to run an instance in gcp to run the tunnel daemon?
AYes, you'll need somewhere running cloudflared that has access to your database, for the traffic to egress from
ADoes Hyperdrive have any mechanism for rotating the connection string or are you supposed to change the ID and re-deploy workers? Tried looking around, but couldn't find anything on this.
MThe connection string is unique to the Worker you call it in and can’t be used outside Hyperdrive or your account, so it can’t be leaked. cc @thomasgauvin for docs here.
AWhat Matt said, the Hyperdrive ID and your connection string are not secrets. Also, if the underlying secrets (password/client secret) were leaked, those can be updated either via Wrangler or API, so you don't need to make a whole new Hyperdrive if it isn't convenient.
HWhat would be the process if you need to rotate because you are switching providers(or for another reason)?
HJust swap out the IDs?
AAt some point it's probably easiest to make a new one for the new provider, and then just swap out the ID in wrangler.toml, yeah.
MHowdy! Is there any type of logging viewable for hyperdrive private database tunnels? I have a postgresql server that is connectable directly via ssh port forwarding, via the tunnel established for hyperdrive
cloudflared access tcp, and of course on the machine itself. However, running the recommended test code (const sql = postgres(env.XXXX.connectionString);) results in a connection timeout with no further info provided. Thanks!
CDid anyone managed to connect a digital ocean manage postgres to a worker?
Ctried with both hyperdrive and none and it just times out, on my local it works perfectly
MYeah, that's the same issue to which I was referring in my thread yesterday (hyperdrive) - I was building a full-stack in Workers Pages and the local hyperdrive dev connection worked OK, but the hyperdrive private connection seemed to be unable to talk to the tunnel, timing out in the process. I had a very productive chat with @AJR, who is looking into the issue
AMay or may not be the same issue. Is the DO connection behind a tunnel? Or publicly accessible?
NIs there a better channel for asking questions specific to Tunnels? I'm having a connectivity issue setting up my database, but believe I've isolated it to the Tunnel.
NI followed the instructions at https://developers.cloudflare.com/hyperdrive/configuration/connect-to-private-database/ and wanted to test database connectivity, so I allowed myself through the Access Application, and am receiving connection timeout errors while trying to connect directly from pgAdmin.
Cloudflare Docs
Hyperdrive can securely connect to your private databases using Cloudflare Tunnel and Cloudflare Access.
AIf the questions are specifically about Hyperdrive through a tunnel this is the channel. Have you had a chance to look through some of the debugging points in this thread?
hyperdriveHowdy! Is there any type of logging
hyperdriveHowdy! Is there any type of logging
NI read about the logging there, and found that no logs were being generated by my connection attempts.
AOkay. If you DM me your hyperdrive ID, I'll dig a bit when I'm back in office Monday and see what I can turn up
NThank you! I'll try to do a bit more troubleshooting this weekend, and will send that over if it doesn't work.
Cpublic accessible: here you have a reproduction if it helps: pages-helpPostgres timesout on cloudflare:
I disabled hyperdrive for the reproduction, the the issue is the same (with/without hyperdrive)
I disabled hyperdrive for the reproduction, the the issue is the same (with/without hyperdrive)
AIf hyperdrive is out of the equation it gets harder for me to help with that, I'm afraid. I'll ask internally on Monday and see if anyone on some of the other dev platform teams knows something about it
JHey everyone, cross post here from the Rust channel and wondering if anyone can help.
Is anyone else using Rust alongside a Postgres database with Hyperdrive? I'm getting some weird intermittent connection issues, that is like either the worker can't connect or is timing out. I'm wondering if it's something to do with this background work happening and the connection not quite being ready.
Is anyone else using Rust alongside a Postgres database with Hyperdrive? I'm getting some weird intermittent connection issues, that is like either the worker can't connect or is timing out. I'm wondering if it's something to do with this background work happening and the connection not quite being ready.
J
JAdditional context, when I run locally with a local database it works absolutely fine
JOk, so I figured this out and just following up here.
It's actually to do with using SQL prepared statements. There's a great write up here. If I switch all the queries to use
https://exograph.dev/blog/wasm-pg-explorations-2#hyperdrive-with-the-extended-query-protocol
It's actually to do with using SQL prepared statements. There's a great write up here. If I switch all the queries to use
query_typed it works perfectly. If the folks building Exograph are around then thankyou https://exograph.dev/blog/wasm-pg-explorations-2#hyperdrive-with-the-extended-query-protocol
AYes, the exograph folks are around here occasionally, and that's a good write-up. While we don't officially support extended protocol messages in tokio-postgres right now, their fork seems to work quite well for people.
MIIRC they merged this into mainline a little while ago: https://github.com/sfackler/rust-postgres/pull/1147
GitHub
Introduce a new query_with_param_types method that allows to specify Postgres type parameters. This obviated the need to use prepared statements just to obtain parameter types for a query. It then ...
AOh cool, I missed that one entirely. Nice!
AI noticed that Hyperdrive now supports prepared statements, but that the docs have not been updated to reflect this change.
I'm wondering if it now supports
I'm wondering if it now supports
SET statements, too, but the docs just isn't up to dateCloudflare Docs
Connecting to traditional centralized databases from Cloudflare’s global network which consists of over 300 data center locations 
presents a few challenges as queries can originate from any of these locations.
presents a few challenges as queries can originate from any of these locations.ANo, the PREPARE keyword is still not supported I'm afraid. Named prepared statements at the protocol level are supported now. This was to support the default behavior of some key drivers in the ecosystem.
TWe documented how you can use Hyperdrive bindings from Pages here! 
https://developers.cloudflare.com/pages/functions/bindings/#hyperdrive-configs
Note that you will need to use Postgres.js, and set Node.js compatibility using the following configurations in your wrangler.toml
(This was mentioned in a separate thread but raising this in the main channel so all can see!)
https://developers.cloudflare.com/pages/functions/bindings/#hyperdrive-configsNote that you will need to use Postgres.js, and set Node.js compatibility using the following configurations in your wrangler.toml
(This was mentioned in a separate thread but raising this in the main channel so all can see!)
NDoes Hyperdrive produce error logs that are visible somewhere? All I'm seeing returned to my worker is "TypeError: Cannot redefine property: query", and nothing in the Tunnel logs.
AThat's a JS error, Hyperdrive isn't throwing that one.
AExample: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors/Cant_redefine_property
MDN Web Docs
The JavaScript exception "can't redefine non-configurable property" occurs when it was
attempted to redefine a property, but that property is non-configurable.
attempted to redefine a property, but that property is non-configurable.
ATo answer the actual question, though, we return all errors from the origin server, plus selected Hyperdrive-specific errors, as Postgres errors to your PG client. The recommended path here is to handle errors from your driver, and either log or condition on them as needed. Logging them will have them populated with all the other Worker logs
BSorry if this is a naive question. I saw on How Hyperdrive works | Hyperdrive that
SET statements aren't supported. In that case, how would I perform an UPDATE statement without using a SET statement?Cloudflare Docs
Connecting to traditional centralized databases from Cloudflare’s global network which consists of over 300 data center locations presents a few challenges as queries can originate from any of these locations.
presents a few challenges as queries can originate from any of these locations.
KYou might be confusing the
SET keyword within an UPDATE statement with the unrelated SET statementKThe
SET statement is for changing run-time configuration: https://www.postgresql.org/docs/current/sql-set.htmlBI was confusing the two. Thanks so much for the help kian!
YNew how-to configuration for Hyperdrive https://developers.cloudflare.com/hyperdrive/configuration/rotate-credentials/
Cloudflare Docs
You can change the connection information and credentials of your Hyperdrive configuration in one of two ways:
AThis is a scenario where the Postgres syntax is a bit unfortunate. SET in the context of UPDATE commands (keyword) and SET in the context of session state management (statement) are entirely unrelated, from the message protocol all the way down to the internals and back. They just happen to share the same name.
SET ROLE and such that are for session state management are going to be a problem, almost regardless of how you wrap them. We've done work to make the system more resilient, so you might get lucky, but generally I'd avoid those.
The SET keyword in the context of UPDATE statements is fine, go nuts with it.
SET ROLE and such that are for session state management are going to be a problem, almost regardless of how you wrap them. We've done work to make the system more resilient, so you might get lucky, but generally I'd avoid those.
The SET keyword in the context of UPDATE statements is fine, go nuts with it.
AI will say that the root cause of problems here is polluting state on shared/pooled connections, so if you scope that state pollution such that by the time your query resolves everything is back how it started, it seems to me that you're less likely to have problems. If you can make it work for your use case, we certainly aren't going to stop you. But it's not something we support so, y'know, we won't be able to help you much. And we do reserve the right to change things in ways that might break that workflow if we need to. Kind of "undefined behavior, in the programming languange sense" territory.
THey folks! It's great seeing all the feedback for Hyperdrive with private databases using tunnels, if you've been trying out and using it for the past few weeks, we want to learn more about your experience.
Likewise, if you've been using Hyperdrive, would love to chat 20-30 mins to better understand how you're using Hyperdrive, what are some of your asks around feature updates, how your performance has been, etc.
We have a bunch of improvements under way to improve compatibility (custom certs
) and performance and we want to make sure we're taking in your feedback! Here's my calendar -> https://calendar.app.google/b3w5dNYQj9YANw449
Likewise, if you've been using Hyperdrive, would love to chat 20-30 mins to better understand how you're using Hyperdrive, what are some of your asks around feature updates, how your performance has been, etc.
We have a bunch of improvements under way to improve compatibility (custom certs
) and performance and we want to make sure we're taking in your feedback! Here's my calendar -> https://calendar.app.google/b3w5dNYQj9YANw449
DHi, its there an updated timeline for MySQL support? (like early/beta/unstable access)
(MariaDB 10, 12GB database, ~ 200 Read Query/day)
tks
(MariaDB 10, 12GB database, ~ 200 Read Query/day)
tks
ANot a timeline we can share publicly yet, no.
I'll say that nobody has beta access yet, but when we get that ready we'll be asking/DMing folks. If you're interested I'll keep a note to see about reaching out to you.
We have to land custom cert support and some pretty important perf work first before we add on new features of that scale.
Also, please do hit up @thomasgauvin so he can get some details about your use case. We want to make sure that when we do ship MySQL support we don't miss features of it that a bunch of people need.
I'll say that nobody has beta access yet, but when we get that ready we'll be asking/DMing folks. If you're interested I'll keep a note to see about reaching out to you.
We have to land custom cert support and some pretty important perf work first before we add on new features of that scale.
Also, please do hit up @thomasgauvin so he can get some details about your use case. We want to make sure that when we do ship MySQL support we don't miss features of it that a bunch of people need.
MHi! I'm trying to set up a VPS with Postgres via docker compose and then bind it in a worker via Hyperdrive.
I have followed the instructions line by line except when setting up the public hostname: instead of localhost:5432 -> postgres:5432.
When the API calls the Hyperdrive returns 504 (Gateway Timeout) to the client. To make sure the DB is working, I have tried to access the database from the VPS console through postgres:5432 and it works fine.
Any suggestions?
I have followed the instructions line by line except when setting up the public hostname: instead of localhost:5432 -> postgres:5432.
When the API calls the Hyperdrive returns 504 (Gateway Timeout) to the client. To make sure the DB is working, I have tried to access the database from the VPS console through postgres:5432 and it works fine.
Any suggestions?
MHey! Seems like this has already been asked, but I wanted to ask if there's been any updates - I want to test hyperdrive with my vercel (nextjs) project. I have plans to switch to cloudflare, but don't have the bandwidth ( 
) to fix all the bugs that'll come up in the migration - yet. Either way I want to test if hyperdrive can speed up my platform by any means.
) to fix all the bugs that'll come up in the migration - yet. Either way I want to test if hyperdrive can speed up my platform by any means.
AShort answer is that this isn't something that's likely to happen any time soon. While I wouldn't close the door on it ever happening, it's not on our radar for the time being.
