SYSTEM Cited by 1 source
Cloudflare Hyperdrive¶
What it is¶
Hyperdrive is Cloudflare's database connectivity service for Workers talking to central SQL databases (Postgres, MySQL). It sits between the Worker and the origin database and "manages database connection pools and query caching to make database queries fast and reliable" (Source: sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers).
Original introductory post (referenced, not ingested on this wiki): How Hyperdrive speeds up database access.
Role¶
Hyperdrive addresses two hazards that fall out of running serverless edge compute against a centrally-located SQL database:
- Connection churn. Workers are short-lived and highly parallel; opening a fresh Postgres / MySQL connection on every invocation exhausts the DB's connection-count budget and pays TLS + handshake cost per request. Hyperdrive pools connections against the origin so individual Worker invocations borrow from a warm pool.
- Repeated read traffic. Many SQL workloads re-execute
the same
SELECTmany times. Hyperdrive caches query results in front of the DB so identical queries don't burn an RTT + DB CPU.
Binding shape¶
Hyperdrive is configured as a first-class Workers binding
(wrangler.jsonc):
Application code uses a standard Postgres client (e.g.
pg) against
env.DATABASE.connectionString:
import { Client } from "pg";
export default {
async fetch(request, env, ctx) {
const client = new Client({ connectionString: env.DATABASE.connectionString });
await client.connect();
const result = await client.query("SELECT * FROM pg_tables");
// ...
}
}
(Source: sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers § "Postgres & MySQL for Workers".)
Hyperdrive speaks the DB wire protocol to the origin, so existing ORMs and clients work unmodified — the Worker thinks it's talking to a normal Postgres / MySQL server, but routing, pool reuse, and caching all happen inside Hyperdrive.
Integration with PlanetScale (2026-04-16)¶
Hyperdrive is the connectivity plumbing for the Cloudflare × PlanetScale partnership announced in September 2025 and extended on 2026-04-16 with dashboard-driven provisioning + Cloudflare-billed flows. Customers provisioning a PlanetScale Postgres (or MySQL / Vitess) database from the Cloudflare dashboard get a Hyperdrive binding auto-created pointing at that database; the Worker talks to Hyperdrive, Hyperdrive talks to PlanetScale (Source: sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers).
Together with an explicit
placement hint ("placement": { "region": "aws:us-east-1" }),
Hyperdrive + placement close the
edge-to-origin
database latency gap: the Worker runs in the Cloudflare POP
co-located with the PlanetScale region, the pooled / cached
Hyperdrive connection avoids per-query handshake cost, and
multi-query request paths stay within single-digit-millisecond
budgets (the forward-looking target Cloudflare names for
auto-placement).
Design-shape takeaways¶
- Caching proxy tier in front of SQL: sibling of the broader patterns/caching-proxy-tier pattern applied to the relational-DB tier rather than the service-mesh tier.
- Partner-managed-service integration vehicle: Hyperdrive is how Cloudflare makes any hosted Postgres / MySQL origin look like a native binding to Workers code — the vehicle behind patterns/partner-managed-service-as-native-binding as exercised by the PlanetScale integration.
Seen in¶
- sources/2026-04-16-cloudflare-deploy-postgres-and-mysql-databases-with-planetscale-workers — Hyperdrive is the connectivity layer under the PlanetScale × Workers integration. Auto-created bindings, standard Postgres client on top, connection-pool + query-cache framing, companion to placement hints for DB-region co-location.
Caveats / gaps¶
Hyperdrive internals are only lightly touched in the 2026-04-16 post. Undisclosed on this wiki so far: pool size / per-tenant connection budget, cache invalidation policy, staleness semantics for cached query results, regional topology of Hyperdrive endpoints, cost model, failure semantics when origin DB is unreachable. The prior How Hyperdrive speeds up database access post covers some of this; ingest into this wiki if / when it becomes relevant.
Related¶
- systems/cloudflare-workers
- systems/planetscale
- systems/postgresql
- systems/mysql
- systems/cloudflare-d1 — D1 is Cloudflare's own SQLite binding for fully-edge-resident relational storage; Hyperdrive is the counterpart for customer-owned central SQL origins.
- concepts/edge-to-origin-database-latency
- concepts/network-round-trip-cost
- patterns/explicit-placement-hint
- patterns/partner-managed-service-as-native-binding
- patterns/caching-proxy-tier
- companies/cloudflare