(pages + hyperdrive) question: Can i separate prod and development or do i need two accounts?
(pages + hyperdrive) question: Can i separate prod and development or do i need two accounts?
I"This repository is being used for a Cloudflare Pages project on a different Cloudflare account." Nop, not even that.
Iforked and works
WYou can use the production and preview environments, e.g.
Docs: https://developers.cloudflare.com/pages/functions/wrangler-configuration/#configure-environments
Docs: https://developers.cloudflare.com/pages/functions/wrangler-configuration/#configure-environments
Ibut this means that I being a developer can switch my preview branch hyperdrive binding and access the production database, right?
KHi, I believe you could run drizzle with both postgres-js and node-postgres drivers, or does this piece of the documentation relate to something else entirely? https://developers.cloudflare.com/hyperdrive/configuration/connect-to-postgres/#supported-drivers
Cloudflare Docs
Hyperdrive supports PostgreSQL and PostgreSQL-compatible databases, popular drivers and Object Relational Mapper (ORM) libraries that use those …
Khttps://orm.drizzle.team/docs/get-started-postgresql#supabase Step 3 shows how you could use the Postgres js driver with drizzle.
Drizzle ORM is a lightweight and performant TypeScript ORM with developer experience in mind.
SI'm using drizzle myself with node pg (https://www.npmjs.com/package/pg). Everything is working correctly, or is that not your question?
KNo I was just pointing out that the docs may potentially be misleading when it mentions drizzle only works with node postgres when you can run it using the recommended postgres-js client.
AAh good catch, thank you!
EIs hyperdrive down?
EFor the past 40 to 50 minutes. Out of nowhere I get cannot get it...failed to aquire a connection from the pool.
ENothing changed. I haven't touched code for the last 6h ...
EAll was working...and I can connect directly to the db.
ATaking a look
EThank you AJR
AWhat's your hyperdrive ID?
AI'm still seeing normal global traffic levels, no elevated error rates.
Esent DM
DDoes hyperdrive work with Cloudflare pages or just workers for now?
Wit's supported on Pages
DThanks, I get this error in the build logs, I have the binding defined in my wrangler.toml. Investigating 
. I asked the question becuase I didn't see the binding in pages UI, but good to know that it works!
. I asked the question becuase I didn't see the binding in pages UI, but good to know that it works!
DAha, got it working, for anyone who runs into this, in the end it was simpler than I thought, just need
compatibility_flags = [ "nodejs_compat" ]wrangler.tomlnode_compat = truecompatibility_flagsI am not sure if this fix should happen in Cloudflare or Remix but I need to provide a "fake" env var "WRANGLER_HYPERDRIVE_LOCAL_CONNECTION_STRING_HYPERDRIVE" for
I think this should be fixed in Cloudflare (it should detect that it is running in the CI and not fail with the "when running locally" message)
remix vite:buildI think this should be fixed in Cloudflare (it should detect that it is running in the CI and not fail with the "when running locally" message)
MIf you're interested in how Hyperdrive works under the hood, @AJR just published a blog: https://blog.cloudflare.com/postgres-named-prepared-statements-supported-hyperdrive
The Cloudflare Blog
Hyperdrive (Cloudflare’s globally distributed SQL connection pooler and cache) recently added support for Postgres protocol-level named prepared statements across pooled connections. We dive deep on what it took to add this feature.
KIs there a way to specify read replicas for a hyperdrive configuration?
TNot currently possible, how many replicas do you have? Which db provider are you using?
SWill read replicas be supported in the near future, like when using SELECT queries Hyperdrive automatically uses the nearest Postgres servers? Ideally with the same set-up as HTTP load balancing
AWe are using Hyperdrive, but it seems to be very slow. A query that should take 20ms-30ms is actually taking 800-900ms. The dashboard reports a query latency of 150ms, but it should still be less than 800ms. The database is located in Bangalore (BLR) and the worker is in Chennai (MAA), so they are quite close to each other.
AIs there a way to check in which location the hyperdrive is?
A@anirudh What is your hyperdrive ID? Send it in a DM?
Is this consistently the latency you're seeing, or is this a spike?
Is this consistently the latency you're seeing, or is this a spike?
AWe have made some changes since June 15th, yes. Please DM me with some details of your setup, if you wouldn't mind. Where's your origin DB, where are most of your users, what driver/version are you using, and any other info you're able to share.
AAlso, is this slowdown still going, or is it back to normal when connected with Hyperdrive now?
AIf you wouldn't mind DM'ing me the Hyperdrive ID, I can confirm. Based on what you've said so far, no I don't think you should switch back at this time if you have a reasonably workable alternative. I have a suspicion about root cause here, but will confirm.
EThere is any list that I can use to limit hyperdrive connections to my postgres to be only accept cloudflare ips? , I'm running a postgres server but not very confortable to be too open to internet.
JHi! Any updates about supporting tunnels?
AIn progress, currently being actively worked on. We'll make announcements when they're good to go.
At the moment I'm able to run most of our test suite across a tunnel, so that's exciting. Not quite ready for prime time yet, though.
At the moment I'm able to run most of our test suite across a tunnel, so that's exciting. Not quite ready for prime time yet, though.
PI'm sorry to have so many things go wrong, but I'm also seeing latency issues with hyperdrive. The pictures, in order:
- localhost
- me → cf hosted worker
- me → VPN to europe → cf hosted worker
All three of these are connecting to the same database. So, it would appear, just by connecting to a cloudflare server within a 50 mile radius of me, the response time has doubled. The VPN has a 100ms overhead. Obviously in all cases its not fast, but the difference is staggering. For the record, a query not involving the database takes 50-59ms without the VPN, and 150ms with the VPN
PConcidently I'll be in europe tonight (US east rn) so I'll be curious to see the speeds there
POf course, all of these are on a warm connection
Pif you'd like, I could run a test of CF worker → database without hyperdrive
ASure, that'd at least test how much of this is due to where your pool is being placed, and how much is the overhead of the VPN/routing itself.
AJog my memory, you're putting your DB in Europe?
PYeah, germany
PI have a lot of customers who would prefer it there, but I would be willing to switch cloud providers at least if that could cut down on latency (eg it looks like just from a ping test that aws has 200ms faster from here to germany)
AMy immediate guess is that the VPN to Europe is doing a lap back to a pool in the US based on your fairly irregular access patterns. All clients in a region are meant to share a pool node so the EU client should be basically all EU->EU and fairly quick, but I wonder if the VPN is passing origin info such that it's being treated as a US source. I'm curious what the non-Hyperdrive latencies look like.
Individual providers are going to have different peering arrangements and different latencies to some degree. Obviously there's a limit to what we can do there. I'm surprised to see AWS be that much faster, though.
Individual providers are going to have different peering arrangements and different latencies to some degree. Obviously there's a limit to what we can do there. I'm surprised to see AWS be that much faster, though.
Pyeah me as well, its shocking but ping tests show similar. So the 350-500ms makes sense, just the local cf looks a bit odd. I'm deploying without hyperdrive now
PNo hyperdrive (US), No hyperdrive (VPN to EU)
PSo it is reducing the time by roughly 100ms in the US, and increasing the time by 100ms in europe
