Race Results: Direct vs Hyperdrive
Same query, same database, 5 sequential runs each, both paths run in parallel. Refresh to run again.
How this demo is wired
🌐
Your browser
Columbus, US
→HTTPS
⚡
Cloudflare Worker
Columbus, US (colo: CMH)
→Postgres
🗄️
Neon Postgres
us-east-1 (Virginia)
What's happening: the Worker ran in Columbus, US (colo: CMH). It made the same SQL query against a Postgres database hosted on Neon in AWS us-east-1 (Northern Virginia). Both paths use the same database — the only difference is whether the connection goes direct (new TCP+TLS+auth handshake every time) or through Cloudflare Hyperdrive (pooled connection at the edge, with optional query caching).
Note for the customer: since this Worker and the database are both in or near US East, the network distance is small — the gap you see here is mostly handshake overhead and caching. In your real architecture, with users globally and a database in one region, the same demo would show much larger savings.
Query executed (x 5 per side)
SELECT id, name, price FROM demo_products ORDER BY price LIMIT 10
Hyperdrive is
1.1x
faster end-to-end
Direct total
790
milliseconds
Hyperdrive total
724
milliseconds
Direct connection
New TCP, TLS, and auth handshake on every request.
Total
790ms
Cloudflare Hyperdrive
Pooled connection at the edge, cached read queries.
Total
724ms
What this shows
- Connection time: Direct took 650ms to open a new connection (full TCP + TLS + auth handshake). Hyperdrive took 2ms — pooled connection already open.
- Caching kicked in: Hyperdrive's first query was 716ms (cache miss, hit the database). Subsequent queries dropped to 1ms — served from edge cache.
- The point: No code changed. Same Postgres database. Same SQL query. Same driver. Just a different connection string — pointing at Hyperdrive instead of directly at the database.