Connection pooling and query caching from Workers to your existing Postgres or MySQL. The bridge between edge compute and regional databases — especially relevant when your Postgres is in af-south-1 and your users are everywhere.
Hyperdrive solves a specific problem: connecting from Workers to a traditional database is slow. Each Worker request is stateless, so without pooling, every request opens a new TCP + TLS connection to your Postgres. That's 5-7 round trips before you even send a query — potentially 200ms+ if the database is in a different region.
Hyperdrive maintains a pool of persistent connections to your database via Cloudflare's network. Your Worker connects to Hyperdrive (fast, on-network), and Hyperdrive reuses an existing connection to your Postgres (already established). It also caches read query results at the edge.
You use standard Postgres client libraries (pg, Drizzle, Prisma) — you just point the connection string at Hyperdrive instead of directly at your database. No code changes beyond the connection URL.
Create a Hyperdrive config pointing to your database, then bind it in wrangler.toml. The binding gives you a connection string your ORM already understands.
# Create Hyperdrive config npx wrangler hyperdrive create prod-db \ --connection-string="postgres://user:pass@db.example.com:5432/mydb" # wrangler.toml [[hyperdrive]] binding = "HYPERDRIVE" id = "abc-123..."
The binding exposes a .connectionString property. Pass it to your Postgres client and everything works as normal — connection pooling and caching happen transparently.
import { Client } from "pg"; export default { async fetch(req, env) { const client = new Client(env.HYPERDRIVE.connectionString); await client.connect(); const { rows } = await client.query( "SELECT * FROM products WHERE category = $1", ["electronics"] ); await client.end(); return Response.json(rows); } };
Hyperdrive eliminates connection overhead, not physics. A query to a Postgres in eu-west from a user in Nairobi still crosses the ocean. It's faster, not magic.
Hyperdrive caches read queries at the edge. For data that changes frequently, you need to set appropriate cache TTLs or bypass caching for specific queries.
Caching only applies to reads. Write latency is unchanged — it's still a round trip to your database's region.