T@alex (he/him) what version of Wrangler are you using? it works on the latest 3.88.0
AI hit it with Neon just now on 3.88.0
TAnd @alex (he/him) do you have IP allowlisting for each developers' IP address? Might be responsible for timeout
A@thomasgauvin I'm using latest 3.88.0, and I have allowed connection from
0.0.0.0/0It also happens for RDS & Neon, so two different provider.. If there is anything else I can provide, logs? Or you want me to run any command, let me know. I can provide those.
TAnd presumably, developers can sign in from local machine to the pg database directly in Node or via PgAdmin?
AYes that's correct! However using the "original" connectionString, I have not tried to use the hyperdrive specific one
postgresql://XXX:XXX@ffca328615404666884948d7d21ccf36.hyperdrive.local:5432/database?sslmode=preferAThe Hyperdrive one won't work outside a Worker, that's an internally-generated identifier
AIf you deploy a random test worker with your configs it behaves as expected?
AAny particular SSL/TLS configuration you've set up on your origin DBs? I assume not, just checking
AProduction works as expected. It really is about
localConnectionString combined with a db not running on localhost.ANo particular SSL/TLS.. I would need to confirm if
localConnectionString works with a db on localhostAAYep. Ok, I'll circle up with Thomas to dig into this when we have some spare cycles. Making this work with remotes is a new feature, and it's worked for us in our testing, but it seems there's some configuration still to be done on our side.
AThanks for letting us know
AWhat did you use in your testing? I'm using RDS & Neon, so two different providers which are quite common.
AI'm using node-postgres 8.13.1
AAre you explicitly using CLOSE statements?
AI would need to confirm if localConnectionString works with a db on localhost
@AJR @thomasgauvin I actually get timeouts too for a db running on localhost
let me go back one version of wrangler
AWell that's not good. That worked fine before.
SThis is occurring for me as well
A3.87.0 also seems to be broken for me.. maybe it's something on my system, but I'm still doubting this
SI got the same error both on 3.87 and 3.88 locally as well
AOk, this is going to take some time to unpack. I'll let the team know.
ASorry for the inconvenience, all
AI'm not using CLOSE statement on my query
A3.86.0 also broken for me
A3.84.1 works for me.. 3.85.0 doesn't work at all, cause it breaks with service bindings
A3.83.0 is the last version before we made the only tweak I'm aware of to local dev
AAh, 3.84.1 works locally? Does it cooperate with local dev against a remote connection string?
BI put together a very simple example repo showing a Worker + Durable object + Hyperdrive (Postgres) integration
https://github.com/shadrach-tayo/cloudflare-worker-example
I just recently migrated our Automerge CRDT sync server architecture to use Partykit + Cloudflare workers Durable Object + Hyperdrive (Postgres) with tunnel deployed in our kubernetes cluster.
Happy hacking weekend guys
https://github.com/shadrach-tayo/cloudflare-worker-example
I just recently migrated our Automerge CRDT sync server architecture to use Partykit + Cloudflare workers Durable Object + Hyperdrive (Postgres) with tunnel deployed in our kubernetes cluster.
Happy hacking weekend guys
GitHub
An example repository showcasing how to implement a Cloudflare worker + DurableObjects binding + Hyperdrive (Postgres) integration - shadrach-tayo/cloudflare-worker-example
HHey @AJR I'm facing the same issue.
ALet me pass that along to the team. Thanks for letting me know.
ATeam checked and things seem to be working right now. We'll have someone reach out to you for details to try to reproduce, if you don't mind.
THi folks. If you're encountering issues when trying to develop locally with Wrangler, please downgrade to 3.85.0. This is a known issue and a fix will be released soon.
https://www.cloudflarestatus.com/incidents/r6ltkr1t0vkr
https://www.cloudflarestatus.com/incidents/r6ltkr1t0vkr
TThis fix has been released in Wrangler version 3.92.0. Please make sure to upgrade if you run into errors with connectivity.
This new version brings back support for localConnectionString for local development with Hyperdrive, with support for databases that do not require SSL.
Support for remote databases (which typically require SSL connectivity) and databases that require SSL more broadly is something we'll continue to work to bring to the Hyperdrive CLI.
This new version brings back support for localConnectionString for local development with Hyperdrive, with support for databases that do not require SSL.
Support for remote databases (which typically require SSL connectivity) and databases that require SSL more broadly is something we'll continue to work to bring to the Hyperdrive CLI.
HHey team, what's the best way of getting more context about these errors ?
Is there an API endpoint I can use to retrieve the error status and messages ?
Do I have to manually log the error on my worker ?
Is there an API endpoint I can use to retrieve the error status and messages ?
Do I have to manually log the error on my worker ?
JIs there any way to use hyperdrive without SSL?
JI tried to enable SSL on my postgres database and for some reason it caused our infrastructure of janky old windows POS machines to fall over
FHey team, I'm seeing an elevated amount of
Error: Connection terminated unexpectedlywaitUntilIt's going to depend mostly on where you host your database and where your users are. Plus whether you cache or not. In general, Hyperdrive itself will add very minimal overhead, single-digit milliseconds generally. Latency for us is about network travel more than anything else.
Except for cache hits, those are stupid fast (and going to get way way faster :soonsoontm: ).
All that said, I think many folks see less than 80ms latencies, so I'd encourage you try it out for yourself.
Except for cache hits, those are stupid fast (and going to get way way faster :soonsoontm: ).
All that said, I think many folks see less than 80ms latencies, so I'd encourage you try it out for yourself.
AMany users point Hyperdrive at Supabase with good success, if you do end up going with them.
AYes. The supabase-js client works well in a serverless environment like Workers, but can't take advantage of CF internals the way Hyperdrive can. So often folks find that postgres.js over Hyperdrive to Supabase ends up being a good fit for them.
ANot that it makes a bunch of difference for your use case, but Hyperdrive is actually all Unix Sockets and RPC under the hood, at least until the queries egress back off our network. Much less overhead than HTTP, yeah.
IAlso the issue with Atlas wasn't HTTP but the fact that MongoDB Atlas actually ran on AWS Lambda, and their cold-start handling was suboptimal so you'd constantly get Lambda cold-starts :NotLikeThis:
IHTTP works fine for DB queries but yeah a connection-oriented protocol is going to be better unless you have a reason to use HTTP
II'd also add that normally HTTP/1.1 and HTTP/2 has TCP Keep Alive which doesn't really exist in Workers because a Worker might be triggered on a different machine at any time and they can't really keep a connection alive the way you could from e.g. a Docker container
ISo you pay for the TCP (+ maybe TLS) handshake every time for HTTP too
T@PatrickJ worth also trying out Hyperdrive + Supabase's Postgres db as well, some customers have done so with good success. You would need to use Hyperdrive as your pooler instead of Supabase's pooler, but that would ensure you have an edge-aware pooler with caching included