Is there any difference, in terms of programming, between using Hyperdrive vs. TCP Connect with Post
Is 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 in the global context?
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) does not currently support connecting to remote databases that require SSL. It is a known gap that we are hoping to address in the future.YSo how do I test and debug locally? Is there any good practice?
ACouple options.
- One is to have a local DB (I keep this alias in my bashrc:
docker run -d -e POSTGRES_PASSWORD=password -p 5433:5432 postgres:16 -c ssl=on -c ssl_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem -c ssl_key_file=/etc/ssl/private/ssl-cert-snakeoil.key) - Use
wrangler dev --remotewhich spawns an ephemeral Worker and will behave like a normal Worker. Still wants alocalConnectionStringbut will use the Hyperdrive binding you give it instead. - Use a remote DB that allows connections with
sslmode=disable(this is probably the hardest to mange given I don't think Supabase supports that)
YI have tried the third method, but supabase does not support it.
KHey, are there any issues with Hyperdrive today? I've been getting 504s for the last half hour or so
ALet me take a look real quick
KThank you! It looks like I'm getting connection timeouts to my RDS
ANo, no changes in general behavior on our monitoring, no releases going out today or anything like that
Kthis is the error i'm seeing in my dev remote instance
AHmmm. DM me your config if you wouldn't mind, and I'll take a look when I'm at my desk.
How regular? 1 in 100 requests? 1 in 100000?
How regular? 1 in 100 requests? 1 in 100000?
Kmy wrangler toml?
Kall requests look like they're failing
YUse wrangler dev --remote, but can not connect the remote worker, it show the bug : Failed to unregister worker TypeError: fetch failed
PI'm trying to make hyperdrive work in a svelte-kit project that uses drizzle. All the examples of hyperdrive usage I could find get
I tried to use process.env, but got no luck here. Can anyone please suggest the proper way to pass the hyperdrive url?
envI tried to use process.env, but got no luck here. Can anyone please suggest the proper way to pass the hyperdrive url?
IYou probably want to recreate the Drizzle instance every time. Something like this:
Then use
This would normally be bad because it reconnects to the DB every createDrizzle call. But it's OK with Hyperdrive because Hyperdrive handles pooling for you.
Then use
const db = createDrizzle(env.HYPERDRIVE_URL, env.SSL) where you need to use it.This would normally be bad because it reconnects to the DB every createDrizzle call. But it's OK with Hyperdrive because Hyperdrive handles pooling for you.
IPlease correct me if I'm wrong on that AJR 
AI'm not familiar enough with Drizzle to answer the original question, but can confirm you're right that the client connection is super fast and would be fine for Hyperdrive.
IThen yeah Drizzle itself is lightweight to create so as long as Hyperdrive is OK then it's good.
AAh, also, wouldn't recommend
prepare: false. We've optimized a bit for the defaults postgres.js uses, so prepare: true will generally be preferable. Especially if you have caching enabled.ANot, like, a huge deal. But since you're in here asking.
IIt would be helpful if the full configuration names were displayed in the list of hyperdrives on the dashboard. Currently, they are truncated, making it difficult to distinguish between similar names.
IWould it also be possible to configure the cache on a per-query basis? Some queries can be cached indefinitely, while others require fresh data every time.
AThis is something that we're actively exploring, it's been a regular request. The challenge is finding a good UX for indicating to Hyperdrive that a query should or should not be cached. We try pretty hard to support as wide an array of ORMs as can use our supported drivers. The various ways they do/don't bundle information into their queries means that a lot of the obvious ways of doing this wouldn't work on various subsets of them.
