MThanks for checking!
KUsing that fork, it seems fine - querying my Neon DB is in the realm of 120-140ms
MIt should. Named prepared statements don’t work with any form of connection pooling as they are connection-scoped in Postgres: https://developers.cloudflare.com/hyperdrive/learning/connect-to-postgres/#transaction-and-statement-support
Hyperdrive supports both PostgreSQL and PostgreSQL-compatible databases, as well as popular drivers and the many Object Relational Mapper (ORM) …
K
KI'll write up the rest in the Gist later
KI originally thought I was going mad after using a non-pooled connection string from Neon in Hyperdrive before I realised that's one of the main points of Hyperdrive, connection pooling. 
KIt'd be nice if Wrangler made a warning/error when you use local development w/ Hyperdrive bindings. You do get a warning that they're experimental, and that callout is made in the docs, but it's an easy issue to hit with local being the default.
KSomething similar to Queues, which tells you that they're not available in remote mode.
KCrossposting from #what-i-built
https://kian.org.uk/using-cloudflare-hyperdrive-with-tokio-postgres-in-workers/
https://kian.org.uk/using-cloudflare-hyperdrive-with-tokio-postgres-in-workers/
Kian's Blog
Cloudflare recently announced their query caching & connection pooling solution for databases in Workers, Hyperdrive.
Whilst there's plenty of examples of using Hyperdrive with libraries like pg in the documentation, someone in the Cloudflare Developers Discord asked about usability with Rust Workers.
There are examples for using tokio-postgre...
Whilst there's plenty of examples of using Hyperdrive with libraries like pg in the documentation, someone in the Cloudflare Developers Discord asked about usability with Rust Workers.
There are examples for using tokio-postgre...
KI think requiring an explicit port number in the connection string is a bit odd and non-standard, though. Could you default it to 5432 like everyone else?
There's an open PR which will do that when merged.
KMy suspicion is that the id can only be used from within my own account, and so it isn't?
Yep.
UAll of the things you have to enter into 
wrangler.tomlD1 database IDs, KV namespaces, Hyperdrive IDs, etc - none are sensitive. It’s all locked into your account.
M“Never make users put secrets in source” 
PDuring the public beta, your account will need to be explicitly enabled by the Cloudflare team.this still true? can I have it?
KThat sounds like it should be specific to Enterprise accounts? @Matt
MWhere is this?
KMEnterprise accounts can also use it. We enabled them.
MThat’s a typo.
KGitHub
Adda a new binding type Hyperdrive as well as a corresponding Service definition ExternalTcpService that allows TCP connections to the designated host address & port
K
UYeah ive noticed a lot with newer products people will attempt to use the bindings but get undefined because they have not updated wrangler... I dont think it would be too hard to look at keys not parsed and be like hey this isnt a valid key you might need to update or something... Or the remote/local thing also
Mcc @penalosa
KGitHub
Describe the solution The current usage of validateAdditionalProperties is only used for a subset of configuration fields, such as build or the top-level entries. This means that you can use the fo...
SQuick questions - in the demo, a new connection is opened for each request (if I'm right). Won't this overload the PostgreSQL server when there're for example thousands of requests each second?
Also, I've created a Hyperdrive Id using wrangler. Should the dashboard in cloudflare change, or will it stay like this?
And last - in local development, I can't access the database (works in prod after wrangler deploy). I'm receiving the following error:
Do I need to add any parameters to the dev start up?
Thank you!
Also, I've created a Hyperdrive Id using wrangler. Should the dashboard in cloudflare change, or will it stay like this?
And last - in local development, I can't access the database (works in prod after wrangler deploy). I'm receiving the following error:
Do I need to add any parameters to the dev start up?
Thank you!
SAh nvm about the local dev.
IHyperdrive is a connection pooler and avoids this exact thing. A few connections are opened from Hyperdrive, and then every request opens a new connection to Hyperdrive (but not the DB) so that your DB doesn't get overloaded.
IBecause connections are held open from Hyperdrive, the connections to Hyperdrive are very very quick and won't overload things.
SAhh ok, that's what I was thinking but I was not sure. Thanks for clarifying
SFor local dev, I'm trying this (pasting a string, if HYPERDRIVE is not available in the env), but I'm getting SSL issues. Is this happening for more people?
Or is my (managed by digital ocean) database cluster not set up correctly?
Or is my (managed by digital ocean) database cluster not set up correctly?
SAlso wrangler defaults to 3.0.0 after installing, should I update to 3.10.1?
MCan you DM me your database URL? There’s not enough info in the issue to debug unfortunately.
MYou need to use the latest version of
Postgres.js- we are waiting for them to publish
3.4.0
MIt's not currently configurable: 20 is very, very low though and would impact performance (fewer conns in the pool == more waiting)
MIs the connection string returned by env.HYPERDRIVE.connectionString usable outside of workers, is it accessible on from workstation when connecting over Warp Teams into the same account ?
KNope
NSo am I understanding Hyperdrive correctly? It's basically the same idea as Cloudflare DNS w/ CDN-style caching but for DBs? That sounds cool...
MAny plans for this? It would be awesome use case to connect into a zero trust with Cloudflare Warps for team, point DataGrip at the hyperdrive endpoint and presume it gets hyperdriven from a near edge, and enjoy the acceleration of less chat between me and live DB 300ms away.