Cloudflare takes Hyperdrive's MySQL pooler to GA after 20 bug fixes
Cloudflare has made Hyperdrive's MySQL support generally available after 20 bug fixes since the beta. Teams running MySQL behind Workers can now weigh it for production, with query caching as the feature to test hardest.
The Engineer · Build desk
Three figures. The empty-response error occurred about 0.001% of the time. A 99.99% availability target leaves 0.01% of room, and the 0.001% fault rate is one tenth of that room. Cloudflare's production availability target is 99.99%.
| Figure | Value | Note | Claim |
|---|---|---|---|
| Empty-response error rate, about | 0.001% | 6 | |
| Room a 99.99% target leaves | 0.01% | 19 | |
| Availability target | 99.99% | 4 |
What happened
- The fault appeared only on Hyperdrive instances with caching enabled, which pointed Cloudflare's search at the MySQL cache path.
- Hyperdrive negotiated utf8, an alias for utf8mb3 that covers 1-3 bytes per code point, so emojis came back wrong until the handshake moved to utf8mb4.
- COM_RESET_CONNECTION restores the server's default encoding, so on a latin1 server a negotiated utf8mb4 connection turned into latin1 after cleanup.
Why it matters
- capability MySQL users on Workers get the pooling and CDN query caching that Postgres users had first, now as a generally available feature.
- exposure A fault at roughly one query in 100,000 surfaced through the heaviest MySQL user, so teams with less traffic had less chance of noticing it on their own.
- cost Connection cleanup now costs a second command per reset, and servers that default to latin1 are the ones whose data the fix protects.
Cloudflare's post puts the gap between beta and GA at "just 20 bug fixes in a trenchcoat" [3]. The beta had one stated job: confirm that real customer traffic met a production availability target of 99.99% [4]. Cloudflare tracks that by counting how often a Worker's client connection ends in a Hyperdrive-related error [5].
A 99.99% target leaves 0.01% of room [17]. The caching fault ran at about 0.001% [6], which is one in 100,000 [18] and a tenth of that room [19]. The comparison is loose. The availability metric counts errored connections, and what the customer reported was an empty response where a non-empty one was always expected [7]. We think a fault at that rate shows up at high volume before it shows up in a test suite.
Cloudflare first combed its telemetry, raised the trace rate on that Hyperdrive instance and searched for network problems. None of it explained the empty responses [8]. At 0.001%, end-to-end traces of a failure were hard to catch [6]. The one clue was that the bug appeared only with caching enabled, so Cloudflare suspected Hyperdrive's MySQL caching [9]. That cache stores common queries in Cloudflare's global CDN cache to cut latency and origin load [10].
The two encoding bugs share a cause. Character set is connection state, and something resets it. The reset is deliberate: Hyperdrive runs COM_RESET_CONNECTION so no session-level state leaks between checkouts [12]. The fix for the side effect is one more command. After every reset, Hyperdrive sets the encoding to utf8mb4 again [13].
The reason to pool at all is cost. Opening a SQL connection takes at least five network round trips, and Cloudflare calls one connection per Worker request impractical [14]. MySQL fares better than Postgres here because it does not give each connection an OS process, but a large connection count can still run into resource issues [15].
The excerpt of the post we reviewed breaks off as it starts to describe Hyperdrive's cache topology. The root cause of the empty responses and any measured availability figure for GA are therefore not covered here. Cloudflare titled the post "Inside Hyperdrive: How we solved a rare Hyperdrive MySQL caching bug" [16].
What to watch
- Cloudflare's explanation of the root cause, which depends on how a Hyperdrive instance interacts with the CDN cache.
- A published availability figure for MySQL against the 99.99% target the beta was meant to validate.
- Reports of empty responses on caching-enabled MySQL instances after the GA release.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence50
- Adoption
- Insufficient
- Hype gap+10
- Incentives
- Insufficient
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Hyperdrive support for MySQL is now generally available.
- [2]
Hyperdrive is Cloudflare's database connection pooler for Workers and initially supported only Postgres.
- [3]
The post says the difference between beta and GA is "just 20 bug fixes in a trenchcoat."
- [4]
During the beta, Cloudflare's goal was to validate that real-world customer usage hit its production availability target of 99.99%.
- [5]
Cloudflare tracks how often client connections from a Worker end in an error related to Hyperdrive, and knew from that tracking that there were reliability gaps.
- [6]
The empty-response error occurred about 0.001% of the time, which made it very hard to find relevant end-to-end execution traces.
- [7]
Cloudflare's highest-volume MySQL customer reported a small but consistent rate of empty query responses for which a non-empty response was always expected.
- [8]
Cloudflare combed through its telemetry, increased the trace rate for that Hyperdrive instance and searched for network issues, but nothing accounted for the behavior.
- [9]
The bug only occurred on Hyperdrive instances with caching enabled, which made Cloudflare suspect an issue with Hyperdrive's MySQL caching.
- [10]
Hyperdrive can cache common queries in Cloudflare's global CDN cache, reducing latency and load on the origin database.
- [11]
Hyperdrive negotiated utf8 in the startup handshake, a deprecated alias for utf8mb3 that supports only 1-3 bytes per code point while full UTF-8 has a maximum of 4; emojis were not returned correctly until the handshake was changed to utf8mb4.
- [12]
Hyperdrive uses COM_RESET_CONNECTION to clear session state so none leaks between checkouts, but the command resets the connection to the server default encoding rather than the one negotiated at startup, so a connection negotiated as utf8mb4 on a server defaulting to latin1 becomes latin1.
- [13]
The fix is to always run a command setting the encoding to utf8mb4 after a connection reset.
- [14]
Establishing a connection to a SQL database takes a minimum of five network round trips, and doing so for each request on Workers would be impractical.
- [15]
MySQL fares better than Postgres because it does not use an entire OS process per connection, but a typical deployment can still run into resource issues with a large number of connections.
- [16]
The post is titled "Inside Hyperdrive: How we solved a rare Hyperdrive MySQL caching bug."
- [17]
A 99.99% availability target leaves 0.01% of room.
- [18]
A 0.001% rate is one occurrence in 100,000.
- [19]
The 0.001% fault rate is one tenth of the 0.01% room a 99.99% target leaves.
Get this ledger inside ChatGPT. Ask about any of our stories and the answer brings its figure, each claim’s verdict and the sources. Free, no account.
Sources
1 independent publisher whose own reporting we read for this story.
- blog.cloudflare.comInside Hyperdrive: How we solved a rare Hyperdrive MySQL caching bug
1 article · October 14, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.