Are there any plans to support MongoDB with Hyperdrive? Would be awesome!
Are there any plans to support MongoDB with Hyperdrive? Would be awesome!
MNot in the near term, but we're talking with MongoDB. Their driver architecture makes it extremely complex, and their drivers themselves don't run in any edge serverless (Workers/Deno/Bun/etc) runtime today.
KIs it now free to use or just available for people who have a paid worker plan?
KUhh someone know how to fix that?
CFree to anyone on a paid Workers plan
KThat means you need a Worker paid plan
CCorrect. But there is no extra cost for hyperdrive
K
Kis there a trial?
Kno right?
CCorrect. There is not a trial
Ksadge
Kwant to test it and look how to implement
M
MNew tutorial: use Timescale with Hyperdrive + Workers! https://developers.cloudflare.com/hyperdrive/tutorials/serverless-timeseries-api-with-timescale/
In this tutorial you will learn to build an API on Workers which will ingest and query time-series data stored in Timescale (they make PostgreSQL …
SThere’s no difference with a regular Postgres connection in development. You’ll just not benefit from the features Hyperdrive has to offer.
So if you really want to use it now or in the future, the $5 per month for the Paid Workers is really worth it
So if you really want to use it now or in the future, the $5 per month for the Paid Workers is really worth it
.Is there any idea on how much hyperdrive will cost once out of beta?
.I dont want to implement this now just to see that it gets suprt expensive
MWe’re still working on pricing but our goal is to make it extremely affordable.
.Alright
.Just because i got your attention i wanna let you know that i think cloudflare is one of the coolest and most awesome companies out there as a tech person.
CJust to confirm there's still no intent to charge for pooling-only usage?
SHas anyone experienced a situation where, with caching turned on, the same query randomly returns an empty array for a while and then starts to return correct results? I never noticed this issue when caching is disabled.
DThere's no example that shows how to setup Hyperdrive for different environments in the
wrangler.toml[[hyperdrive]][[env.staging.hyperdrive]]
DThanks a lot for that quick answer!
Ais the hyperdrive id I get when i create a new one with wrangler ok to commit to public repo or secret?
ZAnything in wrangler.toml is safe to commit, except if you put anything secret in the [env] catagory
EThe ID is scoped to your account, nobody else can use that ID to glean any information -- except me and the other Cloudflare employees 
RHi all, been trying to explore if it would be possible to use hyperdrive in combination with supabase.js. The idea would be to setup hyperdrive with supabase and then point the supabase web client to use hyperdrive rather then directly querying their global postgres instance. Just haven't been able to find any documentation/ examples how to specify a custom postgres url.
MHyperdrive doesn’t accept arbitrary client connections itself today. It’s designed to help folks use Workers to connect to their databases (including Supabase or Neon!).
Supabase.js makes HTTP requests directly to Supabase’s custom HTTP proxy (likely using pgrest in some way) as well - it’s not something we can really support given it’s very Supabase specific.
Supabase.js makes HTTP requests directly to Supabase’s custom HTTP proxy (likely using pgrest in some way) as well - it’s not something we can really support given it’s very Supabase specific.
MHi folks, what would be good managed postgre candidate to use with hyperdrive? (Or workers in general)
MI see Neon and Supabase mentioned quite often
CJust throwing in my 2c, we evaluated all of the popular “serverless” Postgres DBs and none of them ticked all the boxes/gave us as much confidence as AWS Aurora
CI feel like Neon will be a great choice in a year or two, but rn it seemed to lack some basic features that AWS has
IGoogle Cloud SQL is also quite good if you're already integrated into their ecosystem.
AI know more databases are coming later, but may I still ask if ClickHouse is on your list?
MNot yet, no. The ClickHouse protocol doesn’t have a specification: https://clickhouse.com/docs/en/interfaces/tcp
The native protocol is used in the command-line client, for inter-server communication during distributed query processing, and also in other C++ programs. Unfortunately, native ClickHouse protocol does not have formal specification yet, but it can be reverse-engineered from ClickHouse source code (starting around here) and/or by intercepting an...
MAlso: are you querying ClickHouse on every request? I can’t imagine that will be fast regardless.
DWith hyperdrive’s caching that could become possible 
MThe caching relies on the protocol being specified (and a stable parser being available, plus a JS driver). But I’m asking as if you’re instead just querying it periodically/in a Cron/etc, the HTTP interface for ClickHouse is likely a more straightforward approach right now.
AAh I didn't know. I guess an experiment with their PostgreSQL protocol is necessary
ASry I'm not sure I see why you think this is a problem.
ClickHouse for OLAP is very performant. I use it for about 600 dashboards (for different users), and yes queries every time (but cached with a worker). It's also what powers Cloudflare's Analytics Engine IIRC.
ClickHouse for OLAP is very performant. I use it for about 600 dashboards (for different users), and yes queries every time (but cached with a worker). It's also what powers Cloudflare's Analytics Engine IIRC.
AIt's got an HTTP endpoint to run queries, and honestly I might just stick to the Worker for caching + HTTP. I guess the most interesting part for me was the connection pooling.
MI am very aware of how ClickHouse performs. What I am trying to point out is that if you rely on native ClickHouse support you may be waiting a long time, and that CH’s baseline performance may be “fast” but isn’t commonly sub-second for anything but the most simple queries.
Instead, using a HTTP interface will likely get you moving in the meantime, or trying their Postgres interface (untested).
Instead, using a HTTP interface will likely get you moving in the meantime, or trying their Postgres interface (untested).
AYeah, I use their HTTP interface since Workers didn't have TCP support yet when we decided to use it and I couldn't be bothered with creating and maintaining a HTTP proxy for any other OLAP/time-series DB. Performance-wise, the queries seem to run fast enough (20-200ms, we really aren't the same size as CF), helped with caching, but the latency is spiky (I suspect its due to making new the connections but haven't investigated yet).
AAnyway, it's all good to know. Might try the Postgres interface some time later 
CWorkers have outbound TCP connections.
ANow, yes. Not last year.
DIt's not so supabase specific, actually. One of their core principles is using existing or their own open source software. In this case it's https://github.com/PostgREST/postgrest