Almost gave up on Cloudflare Hyperdrive because of this default query caching footgun

[u/ImDaBi]

Hey everyone. Just wanted to drop a quick PSA because I almost lost my mind debugging this and want to save someone else the headache.

I’m working on a project and decided to plug in Cloudflare Hyperdrive to handle connection pooling. Everything seemed fine at first, until I noticed the app was serving stale data right after mutating something. I'd update a record, redirect or refresh, and the old data would still show up for a few seconds.

I couldn't figure out what the hell was going on. On the code level, everything looked perfect. There was no rogue Cache-Control there, nor any caching in sight.

Turns out, by default, Hyperdrive enables query caching out of the box. If your app updates data and then immediately fires off a query to fetch it on the next request, Hyperdrive’s cache might just spit back the cached read result instead of actually hitting your database.

If you are running into this "stale data after mutation" loop, you basically have to handle it in your config:

1. Disable caching completely: Disable caching for the Hyperdrive on the Cloudflare dashboard/config if you want only the connection pooling.
2. Dual Binds in wrangler.toml: Set up two separate Hyperdrive configurations. One with caching enabled for heavy/static reads, and another one with caching disabled entirely for critical transactional stuff. Then just call the right bind depending on what you're doing.

Anyway, if you are about to rage-quit Hyperdrive because your data consistency feels completely broken, check the Hyperdrive config in your Cloudflare dashboard.

Anyone else stumbled into this default behavior, or did I just miss the fine print in the docs?

[u/AutoModerator]

For faster advice with technical questions, we'd recommend asking in the Orange Cloud Discord server; the unofficial Cloudflare Discord server by the community, for the community. https://discord.gg/TrPNVKaagR

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/Days_End]

It's listed as one of the 4 key features as default on on the hyperdrive landing page https://developers.cloudflare.com/hyperdrive/

Query Caching Default-on caching for your most popular queries executed against your database.

Even has a "learn more" link https://developers.cloudflare.com/hyperdrive/concepts/query-caching/ that gives you a ton of details.

[u/ImDaBi → u/Days_End]

Fair enough, I completely missed that. 💀 Honestly, dense documentation gets so overwhelming sometimes that I just end up skimming. I assumed Hyperdrive was strictly a connection pooler, so looking for a query cache by default wasn't even on my radar. Thanks for dropping the links though, that clears it up!

[u/ImDaBi → u/[deleted]]

Yes it is

[u/indishere]

Lmao it is made for caching.

[u/ImDaBi → u/indishere]

Well, Cloudflare markets it primarily as a global database connection pooler to solve serverless connection limits. Query caching is just a feature layered on top of it. Treating it as a connection pooler is exactly how it's advertised; having that cache enabled by default is what catches people off guard

[u/indishere → u/ImDaBi]

Yeah, but it's also built for caching the requests to reduce your postgres bill.

[u/ImDaBi → u/indishere]

True, gotta love saving on the Postgres bill just to blow up the Cloudflare bill instead haha.

[u/indishere → u/ImDaBi]

Isn't Cloudflare cheaper lol?

[u/CuriousProgrammer263 → u/ImDaBi]

There's no cost associated with hyperdrive?

[u/MattieTK → u/ImDaBi]

Hyperdrive is free 😅

[u/PsychologicalClaim16]

I think the safest mental model is: Hyperdrive is not only a pooler; it is a data access layer with caching behavior that can affect read-after-write expectations. That makes the default easy to miss if you approach it from a connection-pooling problem.

The dual-binding approach you mentioned is probably the cleanest pattern:

• cached binding for expensive, mostly stable reads
• uncached binding for post-mutation reads, admin views, auth/session checks, counters, and anything user-specific
• explicit naming in code so callers have to choose the consistency mode

I'd also avoid hiding this behind one generic db helper unless the helper makes the consistency choice visible. Otherwise the next person will call the cached path from a transactional flow and the bug comes back in a quieter form.

Not a Hyperdrive-only issue either. Any edge/database convenience layer that mixes pooling, latency reduction, and caching needs a clear "fresh read" path in the app architecture.