# Can I use Cloudflare Hyperdrive with Yugabyte? **URL:** \ **Category:** General\ **Created:** [January 19, 2026, 5:36am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878 "2026-01-19T05:36:35Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![kokoskiwi](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kokoskiwi/32/999_2.png) [@kokoskiwi](https://forum.yugabyte.com/u/kokoskiwi)\ **Post date:** [January 19, 2026, 5:36am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/1 "2026-01-19T05:36:35Z")
Hi. I‘m coding a very simple React app. Web app → Cloudflare Worker → Yugabyte now i learned that this doesn’t work because CF Workers can‘t keep the TCP connection open. Chatgpt told me to use hyperdrive. Is that correct? is this the way to go? I use geo distributed yugabyte. Will it route correctly to the right yugabyte geo instance? Or is there a copy paste middleware solution i should use and self-host alongside yugabyte? right now i‘m planning to host yugabyte in USA Germany Singapore (geo distributed rows) chatgpt told me this: **🧠 1)** **Cloudflare Hyperdrive** **(most common “middleware” used today)** Cloudflare Hyperdrive is effectively the de facto way teams connect Workers to an external SQL database (including PostgreSQL or any PostgreSQL-compatible engine like Yugabyte’s YSQL). It solves the hard part of serverless → SQL connectivity: - Workers can use familiar Postgres drivers (pg, postgres.js, ORMs like Kysely/Drizzle) but via a Hyperdrive-provided connection string. - Hyperdrive maintains globally pooled TCP connections to your database so Workers don’t have to establish a new connection on every request. - It also optionally caches query results at the edge for hot reads. - You don’t need your own API backend solely for DB access — Workers talk directly via Hyperdrive. Why people pick it - Removes the pain of connection setup on every Worker invocation (TCP ↔ TLS ↔ auth handshake). - Works with existing tools / drivers with minimal code change. - Makes global scale feel faster without managing connection pools yourself. - Now available even on Workers’ free plan. Typical usage flow 1. Create a Hyperdrive config pointing at your YSQL database. 2. Bind it to your Worker (wrangler hyperdrive create …). 3. Inside the Worker call your database using the Hyperdrive connection string with pg / postgres.js. 4. Hyperdrive handles pooling, routing, and optional caching. Tradeoffs - You’re adding a platform dependency (Hyperdrive) instead of running your own backend service layer. - Some workloads with very complex transactions may still benefit from a full backend layer. ---
**Author:** ![kokoskiwi](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kokoskiwi/32/999_2.png) [@kokoskiwi](https://forum.yugabyte.com/u/kokoskiwi)\ **Post date:** [January 19, 2026, 5:40am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/2 "2026-01-19T05:40:46Z")
chatgpt told me to do this Option A. I‘m wondering if this will increase latency. I‘m hosting yugabyte on hetzner. maybe i should co-host a middlewear on hetzner? idk **Option A (usually best):** **One Hyperdrive per region + choose at the edge** Create three Hyperdrive configs, each pointing at a regional Yugabyte SQL endpoint: - hyperdrive\_us → US regional LB / node addresses - hyperdrive\_de → Germany regional LB / node addresses - hyperdrive\_sg → Singapore regional LB / node addresses Then in Workers: - choose which Hyperdrive binding to use based on request.cf.country, request.cf.colo, or your own region mapping. - (and optionally) use Yugabyte geo-partitioning so the “right” rows are local once you’re connected. This gives you true edge routing control instead of hoping one origin hostname does the right thing. Why this matches Yugabyte’s model: Yugabyte expects apps to connect in a region-aware way (smart drivers / load balancing / region preference), especially in multi-region deployments. ---
**Author:** ![kokoskiwi](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kokoskiwi/32/999_2.png) [@kokoskiwi](https://forum.yugabyte.com/u/kokoskiwi)\ **Post date:** [January 19, 2026, 5:41am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/3 "2026-01-19T05:41:32Z")
option B is shit, right? **Option B:** **Single Hyperdrive + GeoDNS/Anycast origin hostname** You can point Hyperdrive at [db.yourdomain.com](http://db.yourdomain.com) and make that hostname resolve to the nearest regional Yugabyte LB via GeoDNS / latency routing. This can work, but there are two gotchas: 1. Hyperdrive’s pooling is described as being placed “closest to your origin database” — if “origin” effectively changes by resolver location, you need to be careful you’re getting the behavior you expect. 2. Debugging “why did this request hit that region” becomes harder. If you want predictable behavior, Option A is safer. ---
**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\ **Post date:** [January 19, 2026, 7:13am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/4 "2026-01-19T07:13:09Z")
Hi @kokoskiwi > [@kokoskiwi](#): > > now i learned that this doesn’t work because CF Workers can‘t keep the TCP connection open. Who said this? This works the same as if connecting to Mysql/PostgreSQL. > [@kokoskiwi](#): > > Chatgpt told me to use hyperdrive. Is that correct? Since it’s free and included, I believe yes. > [@kokoskiwi](#): > > Create a Hyperdrive config pointing at your YSQL database. You should create a hyperdrive config for every yb-tserver I believe. And then connect to them as if you were connecting to each yb-tserver. > [@kokoskiwi](#): > > **One Hyperdrive per region + choose at the edge** Does hyperdrive accept multiple ips for a single “config” ? * * * What is the language you’re coding in? ---
**Author:** ![kokoskiwi](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kokoskiwi/32/999_2.png) [@kokoskiwi](https://forum.yugabyte.com/u/kokoskiwi)\ **Post date:** [January 19, 2026, 11:16am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/5 "2026-01-19T11:16:50Z")
**2. The main architectural challenge** ⚠ Cloudflare Workers cannot keep long-lived TCP connections. Yugabyte speaks: - YSQL (Postgres protocol) or - YCQL (Cassandra-like protocol) Both require stateful TCP connections. So you cannot connect directly from Workers to Yugabyte. > [@dorian\_yugabyte](#): > > Who said this? This works the same as if connecting to Mysql/PostgreSQL. ---
**Author:** ![kokoskiwi](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kokoskiwi/32/999_2.png) [@kokoskiwi](https://forum.yugabyte.com/u/kokoskiwi)\ **Post date:** [January 19, 2026, 11:19am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/6 "2026-01-19T11:19:49Z")
> [@dorian\_yugabyte](#): > > Does hyperdrive accept multiple ips for a single “config” ? Short answer: No — a single Hyperdrive config points to one hostname / origin, not a list of IPs. Hyperdrive is designed like this: Worker → Hyperdrive → one configured Postgres-compatible endpoint That endpoint is: - a hostname (recommended), or - a single address that resolves via DNS > **[ChatGPT - App Architecture Guidance](https://chatgpt.com/share/696e134c-eff8-8007-9c14-d6fd03caa9d0)** > > Shared via ChatGPT It does not take: - a list of IPs - a node list - a topology description ---
**Author:** ![scott](https://avatars.discourse-cdn.com/v4/letter/s/3e96dc/32.png) [@scott](https://forum.yugabyte.com/u/scott)\ **Post date:** [January 19, 2026, 1:23pm UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/7 "2026-01-19T13:23:00Z")
Option B is sharp and unpleasant to live with, but it isn’t broken. Brief points: It doesn’t matter if workers don’t have TCP in this case; Hyperdrive, not the worker, owns the TCP pool. Cloudflare Hyperdrive functions properly at the protocol level since Yugabyte YSQL talks Postgres. GeoDNS + pooling is the issue with option B; once “origin” changes based on resolver location, connection reuse and troubleshooting quickly become problematic. Hyperdrive is not aware of the Yugabyte topology, but it can accept numerous IPs. It won’t find its way to leaders by magic. Briefly put, option B is brittle but functional. Explicit edge selection combined with one Hyperdrive per region is monotonous, predictable, and the appropriate decision for Yugabyte. ---
**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\ **Post date:** [January 19, 2026, 1:24pm UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/8 "2026-01-19T13:24:02Z")
> [@dorian\_yugabyte](#): > > What is the language you’re coding in? Please answer. Language and driver you’re using. ---
**Author:** ![kokoskiwi](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/kokoskiwi/32/999_2.png) [@kokoskiwi](https://forum.yugabyte.com/u/kokoskiwi)\ **Post date:** [January 20, 2026, 2:30am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/9 "2026-01-20T02:30:04Z")
> [@dorian\_yugabyte](#): > > Language and driver you’re using. Hi I‘m using Javascript for everything inside CF workers they have their V8 environment CF workers might become expensive so i‘m thinking of a separate node server on hetzner later on (or python or Go) - I don‘t really care about the language i have worked with C Python Java JS in my life - thanks to AI its even easier now anyway to code in anything But yea for the start i prefer CF Workers i guess, I want to host yugabyte in hetzner I use YSQL if thats what you mean with „driver“ BTW thank you everyone already for all your help and support 🙏🙏🙏🙏i dont take it for granted ---
**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\ **Post date:** [January 20, 2026, 7:44am UTC](https://forum.yugabyte.com/t/can-i-use-cloudflare-hyperdrive-with-yugabyte/4878/10 "2026-01-20T07:44:47Z")
> [@kokoskiwi](#): > > I don‘t really care about the language i have worked with C Python Java JS in my life It’s not that easy to change stacks. > [@kokoskiwi](#): > > thanks to AI its even easier now anyway to code in anything Not to write correct & complex code. > [@kokoskiwi](#): > > I use YSQL if thats what you mean with „driver“ By “driver” I mean the name of the library that you will use to connect to the db. In python there are “psycopg”, “asyncpg”, etc. > [@kokoskiwi](#): > > CF workers might become expensive so i‘m thinking of a separate node server on hetzner later on Both ways work but you need to decide. * * * The hyperdrive should still work by creating one hyperdrive for each yb-tserver and connecting to each one. No issue not knowing which is the leader (there are multiple leaders at the same time, leader is per-tablet, not per-cluster)