Aren't I still supplying the username/password manually for Hyperdrive?
Aren't I still supplying the username/password manually for Hyperdrive?
IYes, but what I mean is that if you use IAM auth locally you can have a crazy long password that's stored only in Hyperdrive (to prevent accidentally leaking it somehow)
DNot sure I understand, I’m already using a crazy long password.
DI would like to prevent leaking it though.
IAny time you have a password used for production infrastructure, using that same password for local development means that it's much easier to make mistakes.
DOh, I’m using a totally different database.
IE.g you forget to
gitignore.envOh OK, great.
DCould I avoid using a password locally?
Dhmm I think I might be on the right track..
DSeems like CF enforces having a password
Deh, couldn't get
--auto-iam-authnwell, one good news is that with
cloud-sql-proxy0.0.0.0/0@Isaac McFadyen Do you have any opinions on what managed PostgreSQL options are the "best"? Google Cloud SQL seems to be really nice, the cost is reasonable ish, and has near zero downtime even during upgrades.
INot particularely. I use Cloud SQL for another project and it is quite nice, yeah.
DThanks! We use Cloud SQL for two other projects; this is the first time we’re using it for something that runs outside of Google Cloud though. 
GI'm having trouble connecting to my supabase database wether I'm using a pooler connection or a direct connection via hyperdrive. The Hyperdrive binding is
nullFixed it. I used an example where the binding was not accessed correctly
AHyperdrive down?
AStarting to see weird behavior for our Workers, which I can't explain myself
N"Connection terminated unexpectedly"?
ANope. Release rolling out right now to address some corner cases with bulk inserts and very large resultsets. But that wouldn't have been going as of 10 hours ago when you messaged.
What kind of weird behavior?
What kind of weird behavior?
DIs there any difference, in terms of programming, between using Hyperdrive vs. TCP Connect with Postgres.js?
DJust wondering if I'm doing any vendor lock-in here.
AIn terms of how you'd actually use them, if you wanted to port away, no not really. You have the option of designing your app more around cached result speed, and also you probably want to avoid transactions more than if you were using direct connections (though that's true with most any connection pooler so.. eh). Overall it should be very portable, as a part of the userbase for Hyperdrive is meant to be folks with pre-existing databases and apps trying to move onto Workers.
If you find cases where that isn't true, please do mention them here.
If you find cases where that isn't true, please do mention them here.
DThanks! This is for new applications, where we want the option to let some enterprise customers self-host (without us needing to rewrite anything).
T@dave | ai.moda the main difference will be using the connectionString you get from Hyperdrive (ie env.HYPERDRIVE.connectionString) instead of env.connectionString accessed as a environment variable/secret.
Fgetting 500 errors when trying to create hyperdrive connection
Fnot sure if this means anything
FUI did not work either
ANot able to connect my hyperdrive to my existing Neon DB with Drizzle ORM. WHY?
error when running
my
[[hyperdrive]]
binding = "HYPERDRIVE"
id = "<ID>"
i got the ID by running
output:
Then in my
i have created a middlware to attach my DB instance in my requests:
while drizzle is coming from
How can i solve this issue?
also tried using
error when running
pnpm run devmy
wrangler.toml[[hyperdrive]]
binding = "HYPERDRIVE"
id = "<ID>"
i got the ID by running
npx wrangler hyperdrive create linkp-neon-hyperdrive --connection-string="output:
🚧 Creating 'linkp-neon-hyperdrive'
✅ Created new Hyperdrive config
{
"id": "<ID>",
"name": "linkp-neon-hyperdrive",
"origin": {
"host": "ep-old-sky--pooler.ap-southeast-1.aws.neon.tech",
"port": 5432,
"database": "linkp-db",
"scheme": "postgresql",
"user": "hyperdrive-user"
},
"caching": {
"disabled": false
}
}Then in my
src/index.tsi have created a middlware to attach my DB instance in my requests:
export const injectDB = createMiddleware(async (c, next) => {
try {
console.log(
Connecting to database...${c.env.HYPERDRIVE.connectionString}
);
const sql = neon(c.env.HYPERDRIVE.connectionString);
c.req.db = drizzle({ client: sql, schema });
await next();
} catch (error) {
console.error("Database connection error:", error);
throw new HTTPException(503, { message: "Database connection failed" });
}
});while drizzle is coming from
import { drizzle } from "drizzle-orm/neon-http";How can i solve this issue?
also tried using
Postgresnode-postgresneon-http
DIs it safe to use
env.HYPERDRIVE.connectionString
SStuck on runnig wrangler locally.
Implementing Hyperdrive with supabase but when doing it gives error saying "No resposne".
using Remix js
Implementing Hyperdrive with supabase but when doing it gives error saying "No resposne".
using Remix js
Fany idea why querying directly to neon is faster than doing it thorugh hyperdrive?
Fi'm running the same query to compare them, one using postgresjs and hyperdrive and another one using neon serverless driver connecting directly to neon
F30ms vs 120ms
AWhere are you querying from, and where's your origin?
Fquerying from a worker with smart placement, according to the response header the worker is on local-ATL
Fand db is located on us-east-1
ACaching enabled or disabled?
Fcaching enabled
ATry without smart placement and without caching, let me know how that looks? Smart placement doesn't always cooperate with caching products. Caching will also be apples-to-oranges with a serverless driver that can't do that.
We (well, @thomasgauvin did all the actual work) recently did a quick comparison of a bunch of those serverless drivers and by and large found performance very comparable with those settings off, maaaaybe a slight edge to Hyperdrive today. If you're seeing that kind of gap even with those settings off I'd be very curious to figure out why.
As we roll out improvements, though, they'll mostly be of the kinds that serverless drivers can't take advantage of. Things like pool placement, caching improvements, etc. If it's still comparable in 3 months I'll be pretty surprised.
We (well, @thomasgauvin did all the actual work) recently did a quick comparison of a bunch of those serverless drivers and by and large found performance very comparable with those settings off, maaaaybe a slight edge to Hyperdrive today. If you're seeing that kind of gap even with those settings off I'd be very curious to figure out why.
As we roll out improvements, though, they'll mostly be of the kinds that serverless drivers can't take advantage of. Things like pool placement, caching improvements, etc. If it's still comparable in 3 months I'll be pretty surprised.
FWith cache disabled and smart placement now, the query times are more similar; the neon serverless driver seems to be 10-20ms faster
AOk. That's within the ranges we were seeing. Thank you for checking.
Serveless drivers solve a lot of the same problems as Hyperdrive, in pretty different ways. At this time, we do expect perf to be comparable, though cache hits should obviously be faster today.
Serveless drivers solve a lot of the same problems as Hyperdrive, in pretty different ways. At this time, we do expect perf to be comparable, though cache hits should obviously be faster today.
FYeah, that's the behavior I'm seeing. The average seems to be almost the same.
AHyperdrive with caching disabled does ok with smart placement, but it's not as good as it could be. We have another big architecture change in progress that will improve that compatibility a good deal.
FSo, correct me if I'm wrong, but right now, the upside of using Hyperdrive seems to be the caching layer, right?
ADepends on your architecture and how widespread your userbase is.
Hyperdrive beats serverless drivers in the following ways today (again, this list is expected to grow in the near future, stay tuned):
Hyperdrive beats serverless drivers in the following ways today (again, this list is expected to grow in the near future, stay tuned):
- caching layer, as you noted
- automatic connection pooling, don't need to handle that yourself (not as big a deal if your service gives you one the same way)
- uses portable drivers, don't have to build targeting only one origin service (e.g. neon, though we do love them)
- uses CF network for a lot of the transit, which may be more reliable than the local public internet depending on where you are
FGreat work, it's 100% worth it using Hyperdrive today. I can't wait to see what you guys build next. I'm hoping to see MySQL support 
. Although the node MySQL driver doesn't support Workers yet, haha
. Although the node MySQL driver doesn't support Workers yet, haha
YI found that my hyperdriver was never able to connect to the remote library of supabase locally. The tutorial I referred to was
https://developers.cloudflare.com/hyperdrive/configuration/local-development/
and https://developers.cloudflare.com/hyperdrive/examples/supabase/
I am a normal worker among online workers. Has anyone encountered this problem before?
https://developers.cloudflare.com/hyperdrive/configuration/local-development/
and https://developers.cloudflare.com/hyperdrive/examples/supabase/
I am a normal worker among online workers. Has anyone encountered this problem before?
ALocal dev mode (i.e.
wrangler dev