Why database connections are slow in distributed environments
Cloudflare Workers run compute close to users, but traditional databases were not designed for that model. If your database sits in us-east1 on a legacy cloud provider, a Worker in Paris, Singapore, or Dubai pays for every round trip. A single round trip can take up to 200ms, and establishing a new connection requires at least seven: TCP handshake, TLS negotiation, and authentication. That means your code can burn a full second or more on connection setup before the query even goes out.
The problem compounds in serverless environments where function invocations are short-lived. A connection scoped to a single invocation is useful for only milliseconds to minutes, so you pay the connection cost repeatedly. Tools like Neon's WebSocket proxy reduce the handshake to four round trips, but each trip can still take 50-200ms. With Hyperdrive, Cloudflare aims to eliminate that overhead entirely.
How Hyperdrive speeds up queries
Hyperdrive does two things. First, it maintains regional connection pools across Cloudflare's network. A Worker connects to Hyperdrive locally, and Hyperdrive keeps a pool of ready-to-go connections back to your database. That removes the repeated cost of new connections on every request.
Second, Hyperdrive distinguishes read queries from write queries and transactions. Read queries that return from cache—which represent over 80% of typical web application traffic—avoid the trip to your database altogether. Write queries cannot be cached safely, but they still benefit from connection pooling and Cloudflare's backbone routing.
The demo application makes back-to-back queries against the same PostgreSQL database, with and without Hyperdrive, selecting a database on a neighboring continent. Internal testing shows a 17-25x improvement for cached queries and 6-8x for uncached queries and writes, compared to going direct.
What Hyperdrive works with
Hyperdrive currently supports PostgreSQL and PostgreSQL-compatible databases, including Neon, Google Cloud SQL, AWS RDS, Timescale, Materialize, CockroachDB, Google Cloud AlloyDB, and Aurora Postgres. MySQL support, including PlanetScale, is targeted for the end of the year, with more engines planned afterward.
The service is in open beta. Developers on a Workers paid plan can start using it immediately—no waiting list or sign-up form required.
Swapping connection strings, not drivers
A key design constraint was letting developers keep their existing drivers, query builders, and ORMs. Hyperdrive works by generating a connection string that replaces your database's connection string. Nothing else changes in your code.
To make this work, Cloudflare collaborated with maintainers of node-postgres and postgres.js to support Workers' TCP socket API, which is going through the standard process and is expected to land in Node.js, Deno, and Bun.
For a new project, setup takes less than a minute. After creating a Worker project, you supply your database connection string to Hyperdrive via the wrangler CLI, then add the Hyperdrive binding to your wrangler.toml file. Your existing application code works unchanged—the driver receives Hyperdrive's connection string and proceeds normally.
Pricing and roadmap
Hyperdrive's connection pooling will always be free, for both current and future database protocols. During the open beta, there are no usage charges for Hyperdrive itself. Pricing details will be announced closer to general availability, expected early in 2024.
The GA roadmap includes more control over caching and automatic invalidation on writes, query and performance analytics, support for additional database engines, and private network connectivity via Magic WAN and Cloudflare Tunnel for databases not exposed to the public internet.
