Pools across the sea: how Hyperdrive speeds up access to databases and why we’re making it free

Hyperdrive is now free

Hyperdrive, Cloudflare's database acceleration service for Workers, is now available on the free plan. The service lets developers connect Workers to existing SQL databases by supplying a standard connection string, and it works with the database drivers and frameworks developers already use.

Since its launch, Hyperdrive has become a core piece of infrastructure for teams building on Workers. Cloudflare's own engineering teams use it to connect from Workers to Postgres clusters for control-plane operations in billing, D1, R2, and Workers KV. That internal reliance highlighted a broader need: connecting serverless compute to traditional regional databases introduces latency and connection-management problems that don't have many good answers. Opening up Hyperdrive to the free tier is meant to make those solutions available to everyone.

The latency gap

The performance impact is substantial. In a simple benchmark using a standard table, the popular postgres.js driver, and a typical OLTP workload with an origin database in London and a Worker in Chicago, a direct connection took an average of 1200 ms for a set of queries. Swapping the connection string for env.HYPERDRIVE.connectionString — a one-line change with no other modifications — cut that to 500 ms, roughly a 60% reduction. Enabling Hyperdrive's query cache brought it down further to 320 ms, nearly a 75% improvement over the direct connection.

Beyond latency, Hyperdrive provides secure authentication, encrypted transport, and a connection pool that shields the origin database from being overwhelmed during traffic spikes. A demo application is available to compare latencies between Hyperdrive and direct database connections.

Pooling fundamentals

Connection poolers are not new technology. Their purpose is to reduce the overhead of establishing and managing database connections, which consume memory and CPU on the database server. As concurrent connections increase, that overhead becomes a bottleneck. Poolers share connections across clients, and there are three common modes for doing so:

• Session mode: Each client gets a dedicated connection for the duration of its session. Simpler to implement and supports a wider range of features, but limits concurrency.
• Transaction mode: A connection is assigned when a client sends a query or opens a transaction and is returned when that unit completes. Subsequent queries from the same client session may land on different connections.
• Statement mode: Connections are handed out per statement; multi-statement transactions are not supported.

Hyperdrive operates as a transaction-mode pooler, a choice that balances feature support with performance. That design supports high concurrency from many short-lived clients while preserving transactional semantics, which is a primary reason teams choose relational databases. Hyperdrive also enforces limits on the number of concurrent connections, idle connection timeout, and manages prepared statements shared across pooled connections, along with other resource-management concerns. These details are documented in Hyperdrive's platform limits.

The round-trip problem

Existing poolers solve connection sharing, but running a regional pooler from Workers introduces the same fundamental problem as connecting to a regional database: network latency.

Establishing any database connection requires multiple network exchanges. Focusing on PostgreSQL's connection protocol, the sequence breaks down as follows:

1. A TCP startup handshake to establish the transport layer.
2. A TLS handshake to encrypt the connection, typically one round trip for TLS 1.3 but potentially more.
3. Application-level authentication to the database server, which itself requires multiple exchanges.

Even in the fastest cases, establishing a new connection takes a bare minimum of five round trips. In practice, that number can climb quickly. A benchmark measuring roughly 125 ms per round trip between Chicago and London means startup alone costs around 625 ms — unacceptable for a distributed serverless environment. Then there are full round trips: messages sent with a response awaited. Half round trips, where the client sends a message without waiting, don't add latency to the critical path.

Hyperdrive's answer to this: perform those handshakes twice, in two different places.

Inside Hyperdrive's architecture

Hyperdrive has multiple internal subsystems. Two central ones are named Client and Endpoint.

Client has two main jobs. First, it impersonates a database server. When a Worker connects to a database through Hyperdrive, it uses a connection string generated on the fly by the Worker runtime. This routes all traffic to a Hyperdrive process running on the same Cloudflare server as the Worker. The database driver then performs its usual handshake, with Client responding as if it were the actual database server. All of this happens locally — p90 is 4 ms, p50 is 2 ms — a far cry from 625 ms for a remote connection.

Client's second role is to inspect incoming queries and determine whether they can be served from Cloudflare's cache. When there is no cached result available, Client reaches out to the Endpoint subsystem, which manages the actual connection to the origin database. By keeping those remote connections established across Cloudflare's network, Hyperdrive eliminates repeated connection setup and minimizes the round trips required for query processing.

Pooling across the network

The Client and Endpoint components don't just manage the cache — they also handle the physical journey between your Worker and the origin database. When Client gets a cache miss, it requests a connection to the data center where Endpoint runs. Cloudflare's networking platform keeps a pool of pre-established TCP connections between all of its data centers, so no handshake is needed before application traffic can flow. An initialization message carries all buffered queries along with the connection request, letting Endpoint process and stream responses back without wasting a round trip.

Endpoint handles three jobs: impersonating a database client for the handshake, processing query messages like Client does, and deciding when to reach the origin database for uncached results. When it needs to query the origin, it pulls from a limited-size pool of database connections. If a connection is free, it's used immediately and returned once results are in — warm connections are usable in microseconds. If the pool is empty but hasn't hit its cap, Endpoint can open a new connection with the same handshake Client performs, but over a much shorter geographic path (possibly even within the same data center as the origin).

Keeping two connections in sync

Hyperdrive is a transaction-mode pooler: a driver must check out a connection before sending a query or opening a transaction. The difficulty lies in making sure the driver's view of connection state matches what the database actually sees. Hyperdrive guarantees all connections are idle and ready when checked out, but unlike other transaction-mode poolers, it coordinates state across two separate machines — Client terminates the incoming connection beside the Worker, while Endpoint pools connections to the origin wherever it's most efficient. That means no shared state between the two components.

Prepared statements are among the trickiest bits of state to track. They only exist on the specific database connection that created them. When a connection returns to the pool and a different one is checked out, a query expecting a previously prepared statement would fail. Hyperdrive tracks which statements each client has prepared and which exist on each origin connection. If a query needs a statement that isn't on the current connection, Hyperdrive replays the wire-protocol messages to prepare it before forwarding the query.

Choosing where to run

Client always runs on the same server as the Worker, so there's no network hop. The bigger question is where Endpoint runs, since that determines the distance — and therefore the latency — of any new connection to the origin database. A database connection string doesn't reveal the database's geographic location, which makes placement hard, especially for databases inside private networks.

Initially, Hyperdrive used a regional pool approach: the Worker's location inferred the region (e.g., ENAM, WEUR, APAC), and Endpoints were deterministically picked from that region's eligible data centers using rendezvous hashing. That worked but had real drawbacks. The chosen data center might not be closer to the origin than the user, new connections could traverse unnecessarily long paths, and Smart Placement was capped: it could only optimize up to the Endpoint's location, since all queries must route through it.

The replacement discards regional pools entirely. Each Hyperdrive now gets a single global Endpoint in the eligible data center closest to the origin database. Finding that location is solved with two subsystems:

• Edge Validator — already used to verify a Hyperdrive can connect to the origin at creation time, so users get immediate feedback on bad credentials or unreachable hosts.
• Placement — runs the same connection routine from every eligible data center, averages the latencies, and keeps a list of the fastest connections. At runtime, that list determines which Endpoint hosts the pool.

Moving Endpoints next to their origin databases proved to be a significant performance win, with the backfill to existing customers staged across two days in late February.

Why not a serverless driver?

Other teams have tackled the same database connectivity problem with custom “serverless drivers” that reduce round trips and connection times while still connecting clients directly to the database. Those drivers are impressive, but we deliberately chose a different path for two reasons.

First, much of Postgres’s value lies in its mature ecosystem. Most developers have used Postgres before, and that shared knowledge carries across projects. Rather than fragmenting the ecosystem with yet another driver, we prefer to support the popular drivers that already exist and let users keep their familiar tooling.

Second, Hyperdrive doubles as a per-query cache (its alpha codename was actually sql-query-cache). Making that cache effective for geographically distributed users requires careful placement of cached results. Since Cloudflare runs distributed services on its own network, we have a lot of flexibility about where execution happens — so it makes sense to lean on that flexibility to solve both the latency problem and the caching problem together.

How caching works under the hood

Hyperdrive buffers protocol messages until it knows whether a query can be served from cache. For the actual cache storage, it uses Cloudflare’s cache, which exists as separate instances in each data center. Historically, one cache instance sat close to the user (in the Client) and another close to the origin database (in the Endpoint). But the caching logic was tightly coupled to the connection-pooling logic, which limited how much we could exploit the Client-side cache.

As part of a recent refactor that moved Hyperdrive to global Endpoints, we split that logic apart. This matters because with a single global Endpoint, users far from it would otherwise get cache hits served from nearly as far away as the origin. Now the Client buffers protocol messages itself and serves results from its local cache when possible. In those cases, traffic never leaves the data center where the Worker runs, cutting query latencies from 20–70 ms to roughly 4 ms on average — and reducing the network bandwidth Hyperdrive consumes as a bonus.

When the Client’s cache misses, the Endpoint may still have a cached result, since it can field traffic from many Clients worldwide. If so, it returns the result along with its remaining time-to-live, so the Client can serve the query and populate its own cache. If the Endpoint itself has to hit the origin database, the result is stored in both caches. That way, subsequent queries from the same data center get single-digit millisecond response times, and load on the origin database drops for queries coming from any other Client. The design behaves similarly to Cloudflare’s Tiered Cache, with the Endpoint cache acting as a final shield for the database.

Getting started with Hyperdrive’s free plan

With Hyperdrive now available on a free plan, you can start using it with a single Wrangler command or through the Cloudflare dashboard:

wrangler hyperdrive create postgres-hyperdrive 
--connection-string="postgres://user:[email protected]:5432/defaultdb"

A “Deploy to Cloudflare” button is also available for a sample Worker app that uses Hyperdrive with an existing Postgres database. Questions and feature ideas are welcome in the Cloudflare Discord channel.