Skip to content

SYSTEM Cited by 2 sources

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 SELECT many 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):

{
  "hyperdrive": [
    { "binding": "DATABASE", "id": <AUTO_CREATED_ID> }
  ]
}

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-21-planetscale-faster-planetscale-postgres-connections-with-cloudflare-hyperdrive — two-component architecture surfaced explicitly for the first time on the wiki. The post decomposes Hyperdrive into: (a) an edge component that "runs globally from within every Cloudflare data center and prepares the 7 round-trip steps of creating a connection to your database within the Cloudflare global network", and (b) a connection pool "enabled physically close to your database [that] maintains warm connections to Postgres which are automatically given to incoming requests." Two physical tiers, not one monolithic proxy. Also the datapoint for "when NOT to pair Hyperdrive with an explicit placement hint" — the demo keeps Workers user-adjacent (default placement) because Hyperdrive's pooling + caching already collapses most of the edge-to-origin DB latency and the user-to-Worker leg matters more for UX in this workload. Canonical wiki substrate for patterns/db-authoritative-with-websocket-notify — the Worker-to-DB transaction half of the architecture.
  • 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.

Last updated · 542 distilled / 1,571 read