deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

Cloudflare Hyperdrive reaches general availability for MySQL with global result caching

Cloudflare's Hyperdrive pooler now generally supports MySQL for Workers with global query-result caching. A rare cache-encoding bug that returned empty results was fixed by storing one canonical copy of each result.

Cloudflare Hyperdrive reaches general availability for MySQL with global result caching

Hyperdrive MySQL reaches general availability

Cloudflare's Hyperdrive, a distributed connection pooler for Cloudflare Workers, added general-availability support for MySQL on 14 October 2026. According to a Netics write-up on dev.to, the release landed roughly eighteen months after the beta that first extended the service beyond Postgres, and it brings the product's global query-result caching to MySQL workloads.

Hyperdrive holds warm database connections on Cloudflare's network and stores results for repeated queries in a cache local to each data centre, so Worker requests share connections that are already open instead of paying for a fresh handshake on every invocation.

Two nodes, one shared cache

Behind the release sits a consistency bug between the two nodes Hyperdrive runs: a Client node beside the Worker and an Endpoint node beside the database, each with a data-centre cache the two can share when they sit in the same facility. A cached entry is keyed on a hash of the query's wire messages with some normalisation, and the value is the raw result bytes.

The disagreement was about encoding. Each node had been caching the bytes it wrote back to the Worker, so a result stored in one node's format could be read by the other node and translated incorrectly. The failure surfaced as empty query results on roughly 0.001% of requests for one high-volume customer, and it appeared only on instances with caching enabled, which pointed investigators toward the pooled path.

The MySQL capability mismatch

The root cause is a negotiation detail in MySQL's wire protocol. Capabilities are agreed when a connection is established, and one of them, CLIENT_DEPRECATE_EOF, changes how a result set terminates: the metadata end-of-file packet disappears and the final packet becomes an OK packet. MySQL server 5.7.5 and later supports the capability, but a client has to request it.

The popular Node.js driver mysql2 does not request it, while Hyperdrive does. The two nodes therefore operate with different capability sets, and the pooler translates every result set into the shape the Worker's driver expects, inserting end-of-file packets and converting OK packets back. Caching those translated bytes broke the translation in both directions. A Client that found the Endpoint's result in Hyperdrive's own encoding sent it to the Worker untranslated, while an Endpoint that read bytes a Client had already translated passed them to a different Client, which translated them a second time and ended up emitting an early end-of-file packet or hanging.

One canonical copy per result

The correction is a single rule about what goes into the cache: store a single canonical version of every result, encoded with Hyperdrive's own capability set, no matter which node produced it. The Client then translates on the way out, and the Endpoint reads a format it understands. Once the fix shipped, the empty-row reports stopped and the success rate for client connections reached the 99.99% target the beta had set out to validate. That figure is Cloudflare's own, and Netics notes the post cites no independent measurement.

Smaller encoding fixes in the release

Netics counts twenty bug fixes between beta and general availability, two of them encoding defects of the same class at lower stakes. The startup handshake negotiated utf8, a deprecated alias for utf8mb3 covering one to three bytes per code point, so emoji written to the database came back broken; the fix negotiates utf8mb4. The second came from session cleanup between checkouts: COM_RESET_CONNECTION returns a connection to the server default rather than the encoding agreed at startup, so a server defaulting to latin1 handed back a latin1 connection and the pooler had to set the encoding again after every reset.

Performance and migration path

Cloudflare's headline numbers, as reported by Netics: pooling makes queries about three times faster, repeated queries can be up to a hundred times faster from cache, and cached results return in under five milliseconds. Establishing a connection from a Worker to a regional database otherwise costs at least five network round trips on Cloudflare's own count. The documented migration path is a connection-string swap, with mysql2 and mysql among the supported Node.js drivers, and Cloudflare's documentation states Hyperdrive works with any MySQL or Postgres database, including managed services and Postgres-compatible engines.

Why it matters

For teams building serverless backends, MySQL support in Hyperdrive addresses one of the model's persistent frictions: globally distributed compute sitting in front of a single-region database. The bug story is also a transferable lesson for anyone operating a pooled or cached data path — a shared cache with two writers needs one agreed serialisation, and a translation layer needs a clear rule about which side of the cache it runs on. Since the headline figures come from the vendor, teams planning a migration should measure cache hit rates, empty or malformed responses, and connection success rates on their own traffic rather than taking the numbers at face value.

  • #cloudflare
  • #mysql
  • #serverless
  • #database-caching
  • #edge-computing

Related posts