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
Create a Hyperdrive config pointing at your YSQL database.
Bind it to your Worker (wrangler hyperdrive create …).
Inside the Worker call your database using the Hyperdrive connection string with pg / postgres.js.
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.
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.
Single Hyperdrive + GeoDNS/Anycast origin hostname
You can point Hyperdrive at 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:
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.
Debugging “why did this request hit that region” becomes harder.
If you want predictable behavior, Option A is safer.
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.
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
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.
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)
1)
Cloudflare Workers cannot keep long-lived TCP connections.