Not yet, but very soon - we want to support local dev.
Not yet, but very soon - we want to support local dev.
ZHey @Matt, is it possible to use HyperDrive without using workers? My project is already up and running with AdonisJS and I can't move everything to workers atm
MNot yet - we’re focused on making Workers fast - as Worker’s distributed model + expensive database connection setup weren’t a good combination previously. Where is your app running if not Workers?
ZEC2 server with pm2, a good old nodejs app with AdonisJS as a framework and an Aurora database
KWill Hyperdrive (and I guess the TCP API in general) be affected by Aegis' dedicated egress IP, or is that use-case going to be covered by the Tunnel integration when that lands?
MInteresting: candidly, I would be surprised if Hyperdrive is faster here. Long running EC2 VM and Aurora - Hyperdrive’s caching will be nice in some cases but for AWS-to-AWS you’re going to pay egress + latency to get to us. Would love to say we are a win there but if this is same region…
MThis - it’s all dependent on plugging into Magic WAN/Tunnel infrastructure (same thing).
Z@Matt Thanks for the answer, the thing is I want to switch to Vectorize at some point, will there be a point when it's open to non workers users? Or do I need to find a way to push data to Vectorize using my node app, then call a CF Worker to get my vectors and process them on my node app?
MVectorize and Hyperdrive are entirely separate things. You can use Vectorize through a Worker to expose your own API, or use Vectorize’ own API.
M
Interact with Cloudflare's products and services via the Cloudflare API
Z@Matt I understand, I was just hoping for a way to get the full benefits of CF workers without having to rewrite all the code. I guess I will add moving to Workers to the roadmap x)
ZBy the way, Vectorize is built on top of what? I can't find the info or any benchmark
MI would (genuinely) LOVE to understand how you came to understand that you need both - you can’t really benefit from Workers if your app is still directly in EC2. Not sure what architecture you’re thinking here.
Moving your “middleware” (all your database interop code) to Workers can be a good first step though.
Moving your “middleware” (all your database interop code) to Workers can be a good first step though.
MRust, Workers and Durable Objects.
ZIs there any speed benchmark on the way? Already using pgvector right now
MNot yet. We just launched a beta: things will change too much over the coming weeks & months.
KGood news: this works
Bad news:
Bad news:
tokio-postgres and connection pooling don't like each other, so you have to resort to query_raw and whatnot which isn't the nicest.KMThanks 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.toml for bindings will not be secret, I think it would be an extremely bad look if an Internet security company made you enter in a secret value into a config that should be pushed to git 
MD1 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?
MEnterprise 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.