That will be awesome. Thank you!
That will be awesome. Thank you!
RJust a clarification: The use of
simple_queryqueryCloudflare Docs
You can now create up to 25 Hyperdrive configurations per account, up from the previous maximum of 10.
PIs Hyperdrive smart enough to clear the cache of a SELECT query if a mutate has happened for that row? For instance, the user profile is cached but then they change their bio. If they refresh would they still see the old profile until “max-age”?
Imax-age
AWithout getting into browser caching, no Hyperdrive does not do proactive cache purging after volatile queries. It's something we've discussed but would be a non-trivial feature to add and generally is not something users have asked for overmuch.
If you need to bypass cache on specific queries, we don't check cache on any volatile queries, so you could add any such function. For example including
If not purging cache on mutation is a dealbreaker feature for you, it would be helpful for us to understand a bit about your use case, if you'd be willing to chat about it.
If you need to bypass cache on specific queries, we don't check cache on any volatile queries, so you could add any such function. For example including
random()If not purging cache on mutation is a dealbreaker feature for you, it would be helpful for us to understand a bit about your use case, if you'd be willing to chat about it.
II'd also add that max-age is also browser-side along with server-side.
ISo even if Hyperdrive could purge the cache somehow (which seems like a bad idea IMO, a DB connection shouldn't be able to modify my CDN config) then it won't affect browser-side caching anyway.
PHmm seems to be a few caching layers here. Let’s say the user who owns the profile has edited it and expects to see the changes immediately. Is there a way to cache bust just for that user? (I’m not understanding how the browser cache plays along with the hyperdrive layer)
ISo these are the cache layers I assume you have (correct me here if I'm wrong):
- Browser cache, this is local on the user's web browser and based on
. This is quite tricky to bust and you usually disable this for APIs in favor of 2.max-age - Server-side cache, this is the Cloudflare CDN and/or your server and/or the Worker that is serving the API requests. To purge this you need control of the Worker, or if it's the CDN cache you need to make an API call to the Cloudflare API. This is also based on
, but if you want to only cache on the server-side you can usemaxage
instead.s-maxage - Hyperdrive query cache. I don't know many details on this, @AJR would know more about how cache busting works here.
IYour original question was about whether a query in Hyperdrive would auto-cache-purge 1 or 2. It doesn't do that because it's a separate system and it's unintuitive/broken behavior if a database connection cache purges the other layers. The developer should have full control over whether that happens and if so, when and how.
AThat is all correct to the best of my understanding. My answer above about including a benign volatile function is the current best solution for cache busting point 3. We expect to add more polish on that front, though it isn't our highest priority at this time.
IAh completely missed the volatile function part - good to know.
PThanks for the great write up!
MI do think some things are being mixed up here:
- Hyperdrive’s cache is only specific to Hyperdrive (per config ID). The
in Hyperdrive dictates that caches maximum TTL per unique query. It’s not a CDN cache and doesn’t cache any results in the browser.maxage
is just a common name for a TTL-based cache configuration setting.maxage - You can also use Cloudflare’s CDN cache from a Worker or Pages app, but there is no intersection with Hyperdrive (unless you actively choose to insert things into it).
IAh, think you're right - apologies, thought this was referring to the
maxageCache-Control
MHi, am a bit confused about hyperdrive, at the moment i have a node application that is deployed to aws lamda behind api gateway ,
I am using postgres db with prisma orm,
I have set up hyperdrive and run some test, how can I integrate it into my lambda deployment
I am using postgres db with prisma orm,
I have set up hyperdrive and run some test, how can I integrate it into my lambda deployment
MWhere is your database? Hyperdrive is currently focused on making it faster to connect (and query) your database from Workers.
If you’re using Lambda and Aurora in the same region, it won’t make much sense here.
If you’re using Lambda and Aurora in the same region, it won’t make much sense here.
RI have seen mentions in this/workers forum that Hyperdrive's
idI am using postgtres on Neo.tech, does worker only work within the worker and how can it be incorporated into my code.
I am using prisma as ORM
I am using prisma as ORM
T@Muudka are you using AWS Lambda or Cloudflare Workers (I see mentions of both in this thread)? Which database vendor are you using/is it AWS RDS/Aurora?
M@thomasgauvin I am using AWS lambda behind api gateway with Postgres on neo.tech serverless db.
KDo hyperdrive also work with PostgresML?
APosting my response a little more publicly, for visibility's sake.
After looking into it, the way tokio-postgres implements prepared statements and the extended query protocol is rather different than how our supported drivers do it. We will work on adding support for extended queries in that driver, but it will not be very soon (lots of other big features we've committed to first). For the meantime, we recommend using simple queries with that driver. I'll check our docs and make sure that they offer similar guidance.
Note that while @ramnivas did see better behavior with caching, that's somewhat incidental and you're likely to still hit bugs using extended queries in tokio-postgres even with caching enabled.
Thank you @ramnivas for the excellent write-up!
After looking into it, the way tokio-postgres implements prepared statements and the extended query protocol is rather different than how our supported drivers do it. We will work on adding support for extended queries in that driver, but it will not be very soon (lots of other big features we've committed to first). For the meantime, we recommend using simple queries with that driver. I'll check our docs and make sure that they offer similar guidance.
Note that while @ramnivas did see better behavior with caching, that's somewhat incidental and you're likely to still hit bugs using extended queries in tokio-postgres even with caching enabled.
Thank you @ramnivas for the excellent write-up!
R@AJR Thanks for the update.
Meanwhile, for those who want to not use
https://github.com/exograph/rust-postgres/tree/exograph
Meanwhile, for those who want to not use
simple_queryexographquery_with_type_paramshttps://github.com/exograph/rust-postgres/tree/exograph
GitHub
Native PostgreSQL driver for the Rust programming language - GitHub - exograph/rust-postgres at exograph
T@Olivier F @Florent funny you should ask! this is one of our main things in progress currently, we should setup a meeting to talk it through, get some of the details from your side and get your early feedback. These are my availabilities https://calendar.app.google/ynRoYiJudGqyGPRN9
RCheck out our latest blog that makes use of Hyperdrive to improve latency:
https://exograph.dev/blog/cloudflare-workers
https://exograph.dev/blog/cloudflare-workers
We are excited to announce that Exograph can now run as a Cloudflare Worker! This new capability allows deploying Exograph servers at the edge, closer to your users, and with lower latency.
DI use postgres.js (latest version 3.4.4), hyperdrive and supabase. Every now and then a query fails due to
CONNECTION_CLOSED
IWhy does query latency fluctuate so much? It's normally around 60 ms but sometimes down to 10 ms for short periods.
I(pages + hyperdrive) question: Can i separate prod and development or do i need two accounts?
I"This repository is being used for a Cloudflare Pages project on a different Cloudflare account." Nop, not even that.
Iforked and works
WYou can use the production and preview environments, e.g.
Docs: https://developers.cloudflare.com/pages/functions/wrangler-configuration/#configure-environments
Docs: https://developers.cloudflare.com/pages/functions/wrangler-configuration/#configure-environments
Ibut this means that I being a developer can switch my preview branch hyperdrive binding and access the production database, right?
KHi, I believe you could run drizzle with both postgres-js and node-postgres drivers, or does this piece of the documentation relate to something else entirely? https://developers.cloudflare.com/hyperdrive/configuration/connect-to-postgres/#supported-drivers
Cloudflare Docs
Hyperdrive supports PostgreSQL and PostgreSQL-compatible databases, popular drivers and Object Relational Mapper (ORM) libraries that use those …
Khttps://orm.drizzle.team/docs/get-started-postgresql#supabase Step 3 shows how you could use the Postgres js driver with drizzle.
Drizzle ORM is a lightweight and performant TypeScript ORM with developer experience in mind.
SI'm using drizzle myself with node pg (https://www.npmjs.com/package/pg). Everything is working correctly, or is that not your question?
KNo I was just pointing out that the docs may potentially be misleading when it mentions drizzle only works with node postgres when you can run it using the recommended postgres-js client.
AAh good catch, thank you!
EIs hyperdrive down?
EFor the past 40 to 50 minutes. Out of nowhere I get cannot get it...failed to aquire a connection from the pool.
ENothing changed. I haven't touched code for the last 6h ...
EAll was working...and I can connect directly to the db.
ATaking a look
EThank you AJR
AWhat's your hyperdrive ID?
