How interesting. Can you share a code snippet that induces this behavior? How often/reliably does
How interesting. Can you share a code snippet that induces this behavior? How often/reliably does it reproduce for you?
AAside, you should be seeing better caching behavior now, btw, @Ping for toast . How's it looking on your side?
PBy a code snippet, do you mean you're asking for a minimum reproducible example? My configuration is very much like bs_sfalls
- I use solid-start and hyperdrive, and my backend is elysia with hyperdrive.
- The backend is hosted on a separate worker.
- In SSR, two requests are fired simultaneously — one to retrieve data about the current user, and one to fetch the data presented on the page, using service bindings
- This can obviously be triggered by doing a page reload.
- Until said page reload happens, requests work fine
- After n seconds (where n is unknown; greater than 30s and less than 5 minutes?), presumably after hyperdrive disconnects // the worker cools down, it begins working again
PCaching is a lot better — 50% or so
PI also literally just switched db hosts as I thought this would be a good opportunity, so I will test it again to see if it reproduces
AInteresting. We do have some rate limiting in place but it wouldn't be triggered by a single pair of simultaneous requests, and even if it was it would only lock out for a couple hundred ms.
I'm going to have to dig at this a bit. I'll put together a ticket for it
You said this only started within the last week or so?
@bs_sfalls same timeframe for you, just the last week or so?
I'm going to have to dig at this a bit. I'll put together a ticket for it
You said this only started within the last week or so?
@bs_sfalls same timeframe for you, just the last week or so?
Pyup, you can actually see the first time i noticed it
Pright here :)
Pit could have been up to a week tho
PReproduced
PThe reason that it looks like the html has loaded is because of streaming
IYes followed the instructions, using the exact same code as the examples in the documentation. Getting the error 'PostgresError: server requires encryption' when postgres in the Cloudflare worker attempts to set up a connection.
PAny updates on this? If not, would you mind pinging me when there's updates 
, it would be very appreciated
, it would be very appreciatedAWill ping you when we have anything to share on this one. You'd better have toast.
Palways 
Bhi gusy does worker support node-postgres's pg.Pool ? when i building with svelte Cloudflare adapter, i got fs,dns,...etc not supported error
IMake sure you have nodejs_compat enabled in your wrangler.toml.
Icompatibility_flags = ["nodejs_compat"]Morning all! Yep, that scenario is why we sunk some time into getting postgres-js supported, and now recommend it.
Boh ok, maybe it is good idea to put a warning on this page https://developers.cloudflare.com/workers/tutorials/postgres/
Cloudflare Docs
In this tutorial, you will learn how to create a Cloudflare Workers application and connect it to a PostgreSQL database using TCP Sockets. The Workers application you create in this tutorial will interact with a product database inside of PostgreSQL.
AI'll take a look through and add that. Appreciate the suggestion
Thas anyone used hyperdrive with neondb? What is the latency that you guys are getting?
INeon databases are hosted in a single region so you need to use smart placement in the same region to get acceptable latency.
EI personally use a neon database for testing, and get sub 100 millisecond latency on hot connections without caching -- but your results will vary based on where your requests are coming from and where you neon database is located
TI created one in Frankfurt and I'm based in Malta, so I was getting 200-300ms for a single query (not cached I think), using the hyperdrive with postgres.js. Btw, I haven't managed making hyperdrive work with the serverless neondb driver (via drizzle orm), but only with postgres.js. Maybe the serverless driver of neondb is not supported in cloudflare?
Talso, which driver do you recommend using with hyperdrive? Are you using postgres.js yourself as well, instead of the serverless driver of neon?
MThe serverless Neon driver is supported… it’s just slower than Hyperdrive: https://blog.cloudflare.com/hyperdrive-making-regional-databases-feel-distributed/
The Cloudflare Blog
Hyperdrive makes accessing your existing databases from Cloudflare Workers, wherever they are running, hyper fast.
MAll of our docs recommend Postgres.js and our teams internally use it.
M
Cloudflare Docs
Hyperdrive supports PostgreSQL and PostgreSQL-compatible databases, popular drivers and Object Relational Mapper (ORM) libraries that use those drivers.
TThanks for your kind reply. I was referring that I did not manage to use the serverless Neon driver together with Hyperdrive (not separately!). I don't think hyperdrive can work together with the serverless driver without changing it to postgres.js. More info here:
https://orm.drizzle.team/docs/get-started-postgresql#neon-postgres
https://orm.drizzle.team/docs/get-started-postgresql#neon-postgres
Drizzle ORM is a lightweight and performant TypeScript ORM with developer experience in mind.
MThe Neon serverless driver uses WebSockets — because most serverless providers don't have something like Hyperdrive — so they aren't compatible and can't be.
WebSocket-per-request is still slower than using Hyperdrive's connection pooling (by a fair bit, as the blog lays out)
WebSocket-per-request is still slower than using Hyperdrive's connection pooling (by a fair bit, as the blog lays out)
TThank you very much for your detailed reply, this clears a lot of the confusion I had
May I ask about any future plans for Hyperdrive? It's a really amazing product!
Thank you once again! I'll proceed with using postgres.js.
May I ask about any future plans for Hyperdrive? It's a really amazing product!
Thank you once again! I'll proceed with using postgres.js.
LHello there! Has anyone managed to make a NextJS app hosted on Cloudflare Pages to fetch its Postgres database through Hyperdrive?
AThere was an issue with prepared statements and extra round trips to the DB with postgres.js. Has that been resolved?
AWe saw a reduction in latency by using the node-pg driver
MQuite some time ago - we discussed that here too. https://developers.cloudflare.com/hyperdrive/platform/changelog/#2024-05-22
AOh. Let me check again. I remember trying it after sometime in June/July and still having the issue.
Lfor hyperdrive, could I connect to it via a pages app or would I have to use worker sites?
AHyperdrive does work with Pages, yes.
Ldoes Hyperdrive have static IPs I can allow traffic from my RDS Postgres instance?
ANot yet, no. It's on our radar but for now we're still on the shared pool Warp uses, that is not static
AWhen that changes it'll warrant a changelog entry, for sure.
CHas there been any progress in securing Hyperdrive? (sorry - wrote this before seeing the post indicating there are no static IPs yet)
I know Cloudflare has deemed Hyperdrive "producton ready", but it is unusable in its current state for anything more than a sandbox... and certainly not anything targeting the enterprise. The restriction to open 0.0.0.0/0 is a widely known security vulnerability. I did this (since there was no other way), and instantly regretted it. Within a day, my Google Cloud SQL server was hammered with connections attempting to gain access... enough so that the small scale test DB instance I had was shut down for memory consumption (deemed underprovisioned... when there was literally one record getting 5 requests/day in the tiny DB). Google has plenty of ways to secure the DB, but Cloudflare is essentially requiring users to bypass these mechanisms.
I know Neon, PlanetScale, & Supabase are supported... but just supporting Guillermo Rauch-backed startups is not enough to call it "production ready". Contrary to what has been stated, most databases are NOT publicly accessible. Only managed service providers do this, and even those have the ability/recommendation to add security rules limiting connections. I mention this because it was one of the arguments made in favor of allowing 0.0.0.0/0 a few months ago in this thread.
I'd really love to use Hyperdrive. While my servers were left alone, it seemed great. However; this is a deal-breaker if it's going to put my other infrastructure in jeopardy. If there's anything I can do to help, I'd be happy to.
@AJR - is the pool of IP's for warp accessible? If we can restrict by that, it would be a start.
cc @Matt
I know Cloudflare has deemed Hyperdrive "producton ready", but it is unusable in its current state for anything more than a sandbox... and certainly not anything targeting the enterprise. The restriction to open 0.0.0.0/0 is a widely known security vulnerability. I did this (since there was no other way), and instantly regretted it. Within a day, my Google Cloud SQL server was hammered with connections attempting to gain access... enough so that the small scale test DB instance I had was shut down for memory consumption (deemed underprovisioned... when there was literally one record getting 5 requests/day in the tiny DB). Google has plenty of ways to secure the DB, but Cloudflare is essentially requiring users to bypass these mechanisms.
I know Neon, PlanetScale, & Supabase are supported... but just supporting Guillermo Rauch-backed startups is not enough to call it "production ready". Contrary to what has been stated, most databases are NOT publicly accessible. Only managed service providers do this, and even those have the ability/recommendation to add security rules limiting connections. I mention this because it was one of the arguments made in favor of allowing 0.0.0.0/0 a few months ago in this thread.
I'd really love to use Hyperdrive. While my servers were left alone, it seemed great. However; this is a deal-breaker if it's going to put my other infrastructure in jeopardy. If there's anything I can do to help, I'd be happy to.
@AJR - is the pool of IP's for warp accessible? If we can restrict by that, it would be a start.
cc @Matt
MThe pool of IPs used right now is not stable. Do not restrict by that. We’re working on a better approach here that will allow you to use Cloudflare Tunnel + Access for cases where you can’t open your firewall to the Internet.
IP ACLs aren’t/would not be scoped per customer, and we don’t think they’re the right approach.
IP ACLs aren’t/would not be scoped per customer, and we don’t think they’re the right approach.
C@Matt - Timeframe?
A@Corey this is something we're well aware of and addressing it has been our top feature priority. The Tunnel support and our move over to a stable IP pool are under active development. Matt will have to speak to timeframe/announcements etc, but I just wanted to chime in and say that we do hear you loud and clear on this one.
TTo give you an idea of timeline, we’re testing internally. So actually coming soon
TIf (and only if) you've been wanting to connect from Hyperdrive to private databases over tunnels:
@AJR and I talked it over and we're ready for you to try Hyperdrive with tunnel support for private databases early (if you're interested). Docs are still in progress, there may still be some rough edges and it's cli/api heavy (no UI yet), but we're looking forward to getting this in your hands and get your early feedback on it. If you're in,
this message we'll start a separate message thread for us to discuss this later this week.
CC @Corey @berkinovish @amcclosky (because you've brought it up in the past)
@AJR and I talked it over and we're ready for you to try Hyperdrive with tunnel support for private databases early (if you're interested). Docs are still in progress, there may still be some rough edges and it's cli/api heavy (no UI yet), but we're looking forward to getting this in your hands and get your early feedback on it. If you're in,
this message we'll start a separate message thread for us to discuss this later this week.CC @Corey @berkinovish @amcclosky (because you've brought it up in the past)
Mwill we ever be able to set caching at the query level? since hyperdrive is parsing queries it seems like you could have a statement to set cache ttl
AYes, it's on our backlog. It's not something we've really set about yet, so the exact design and behavior of it is an open question, but disabling cache and setting max-age per query are both going to happen at some point.
IThis was awesome timing with the previous message :lul:
