Cloudflare Hyperdrive MySQL pooling reaches GA after rare caching bug hunt

MySQL support in Hyperdrive, Cloudflare's database connection pooler for its Workers compute platform, is now generally available. The company announced the milestone in an October 14 blog post that also recounts the engineering work between the beta and this release — about twenty bug fixes, by Cloudflare's own tally.

Hyperdrive launched with Postgres support only, and MySQL protocol support has been in beta since last year. According to Cloudflare, the beta's purpose was to validate that real customer traffic could meet a 99.99% production availability target, which the team monitors by measuring how often a Worker's client connection ends in a Hyperdrive-related error.

What Hyperdrive does

Hyperdrive keeps SQL connections warm across Cloudflare's global network and shares them across many Worker requests, and it can also cache common query results in Cloudflare's CDN to reduce latency and origin load. That pooling matters on a serverless platform: establishing a database connection takes at least five network round trips, which is impractical to repeat for every request, and large numbers of open connections carry real per-connection costs. Cloudflare notes that MySQL fares better than Postgres here because it does not dedicate a full OS process to each connection, but a typical deployment can still run into resource issues at high connection counts.

Two character-set bugs

Some of the beta's problems were small and easy to fix once reported. One early report involved emojis that were written to the database but returned incorrectly. Hyperdrive had been negotiating the connection character set as utf8 during the startup handshake — which turns out to be a deprecated alias for utf8mb3, an encoding that covers only one to three bytes per Unicode code point rather than the full four. Switching the handshake to utf8mb4 fixed the issue.

A second encoding bug surfaced when Cloudflare added connection cleanup using COM_RESET_CONNECTION, a lightweight MySQL command that clears session state so nothing leaks between checkouts from the pool. The catch is that this command does not restore the character set negotiated at startup; it resets the connection to the server's default instead. On a server defaulting to latin1, a freshly reset connection would silently lose its utf8mb4 setting. Cloudflare's fix is to always run a command setting utf8mb4 after a connection reset.

A bug that struck 0.001% of the time

The centerpiece of the post is a subtler defect reported by Cloudflare's highest-volume MySQL beta customer: a small but consistent rate of empty query responses in cases where a non-empty response was always expected. It occurred roughly 0.001% of the time, too rarely to capture useful end-to-end traces even after Cloudflare raised the trace rate for that Hyperdrive instance. Network problems were searched for and ruled out. The one clue was that the bug appeared only on Hyperdrive instances with caching enabled, which pointed the team at Hyperdrive's MySQL caching.

A split architecture with a shared cache

Every Hyperdrive instance has two components. A Client node runs on the same machine as the user's Worker, handles local caching when enabled, and forwards queries onward as needed. An Endpoint node holds the connection pool and is placed in the data center closest to the origin database. Each node uses the Cloudflare CDN cache local to its data center — which means that when the two nodes land in the same facility, they share a single cache.

That sharing is normally a performance win: if the Endpoint recently cached the results of a query, a Client in the same data center can serve the response directly. Hyperdrive keys cached entries on a normalized hash of the query's wire-format messages and stores the response bytes, so the scheme is correct only if the same response always produces the same bytes regardless of which node stored them.

The complication is the MySQL protocol itself. Hyperdrive simultaneously acts as a server to the Worker's MySQL client library and as a client to the origin database, and capabilities are negotiated separately on each side during the connection phase. Because those capability sets can differ, Hyperdrive must translate every origin response from its own fixed capabilities into the ones the Worker expects. Unable to catch a live trace of the defect, Cloudflare's investigation pointed to the interaction between this translation and the shared cache as the source of the empty responses.

Why it matters

Connection pooling is what makes traditional SQL databases practical from serverless and edge platforms, and MySQL support extends Hyperdrive beyond its Postgres origins to a much larger installed base. The post also works as a case study in the hidden complexity of protocol proxies: both a fixable emoji bug and a roughly one-in-a-hundred-thousand caching defect stem from the same reality — a pooler sits in the middle of a protocol and must honor every assumption on both sides. For teams running MySQL behind serverless workloads, the GA release now offers pooling and query caching as managed infrastructure.