Cloudflare Edge Platform

Hyperdrive

Database Connection Pooling at the Edge

Stop drowning your database in TCP handshakes. Let Cloudflare's edge handle the connections, so your serverless functions run at wire speed.

The Problem

❌ Why Serverless + Databases Hurt

Every time a stateless Worker (or Lambda, or Edge Function) talks to a traditional database, it opens a brand new TCP + TLS connection. At scale, this creates three pain points:

Pain Point	What Happens	Cost
Connection Exhaustion	Postgres maxes out at ~100–500 connections. 10,000 concurrent Workers = database meltdown.	Downtime, rejected queries
Latency Tax	TCP handshake + TLS negotiation + auth every single request.	50–200ms added per query
Cold Start Penalty	Each Worker invocation re-establishes everything from scratch, even for identical queries.	Slow UX, wasted compute

The Architecture

⚡

Worker

Serverless Edge Function

→

sub-ms

🚀
Hyperdrive
Edge Connection Pool

→

persistent

🐘

Your Database

Postgres / MySQL

How It Works

1. Connection Pooling

✅ Warm, Reusable Connections

Hyperdrive maintains a pool of persistent, authenticated connections to your database from every Cloudflare PoP (300+ cities). When your Worker needs data:

Worker calls Hyperdrive locally

Your Worker talks to Hyperdrive on the same edge node — sub-millisecond roundtrip. No TCP, no TLS, no auth from the Worker's perspective.

Hyperdrive borrows a warm connection

Hyperdrive picks an existing connection from its pool to your database. The database sees a stable, long-lived client — not 10,000 new connections.

Query executes, result returns

The query runs over the warm connection. Result flows back through Hyperdrive → Worker. Connection goes back to the pool.

2. Query Caching

⚡ Read Cache at the Edge

For repeated read queries, Hyperdrive caches results at the edge. Same SELECT comes in again? Served from cache — database never touched.

Scenario	What Happens	Latency
Cache Hit	Result served from edge cache	~1–5ms
Cache Miss	Query forwarded to database via pooled connection	Query execution time only
Write Query	Always forwarded to database; cache unaffected for writes	Query execution time

Note: Cache is TTL-based. You configure expiration globally or per-query. No manual invalidation API — tune TTL to your data freshness tolerance.

Configuration

Hyperdrive is configured in your Wrangler config, not in application code:

# wrangler.toml
[[hyperdrive]]
binding = "HYPERDRIVE"
id = "your-hyperdrive-config-id"
        

Then in your Worker:

// Worker code
const client = new Client({
  connectionString: env.HYPERDRIVE.connectionString
});
        

Your origin database credentials are stored securely in Cloudflare's config — never in code.

What It Supports

Database	Status
PostgreSQL	✅ Primary target — full support
MySQL	✅ Supported
CockroachDB, YugabyteDB	✅ Wire-compatible with Postgres

Pricing

Workers Free

100,000 queries / day
Daily reset at 00:00 UTC
Connection pooling included
Query caching included

Workers Paid

$5/mo min

Unlimited queries
Connection pooling included
Query caching included
No data transfer fees
No hidden limits

Hyperdrive is bundled inside the Workers plan — no separate Hyperdrive invoice. If you're already on Workers Paid, it's effectively free unlimited.

When to Use It

✅ Hyperdrive Shines When...

You serve high-frequency reads from many Workers (user profiles, configs, catalogs)
Traffic is bursty — 10K concurrent Workers won't overwhelm your DB connection limit
Your app is global — Workers in 300 cities, one database in one region
You want to keep your existing Postgres/MySQL — not migrate to a serverless database

❌ Hyperdrive Doesn't Help When...

Your workload is write-heavy — every write still round-trips to origin
You run long transactions — they still tie up a pooled connection
You need real-time data — cache TTL means stale reads; tune to tolerance
Your database is down — Hyperdrive doesn't failover or replicate

"Hyperdrive is PgBouncer at the edge, managed by Cloudflare, with an optional read cache bolted on. It makes your serverless functions talk to your monolithic database without drowning it in connections."