Workers KV bids: metadata and a second source of truth
The Workers Distributed Data team has shipped two notable updates to Workers KV since its last public status check: custom metadata on key/value pairs, and an additional central datastore on the European continent. Both reduce friction for developers working with KV, and the latter should have a measurable impact on write latency outside the US.
Arbitrary metadata, no more guesswork
KV’s interface is intentionally simple: put a key with a string value, get it back later. The trouble starts when the values you store represent different content types — serving a CSS file with a text/html Content-Type header breaks the page, and detecting that per request adds both code and latency to your worker.
A common workaround involves pulling in the mime package from npm, which maps file extensions to content types. Workers can call getType() at runtime, but that means the content type is computed for every single request, and the bundled package’s extension map costs your worker roughly 9kb of script size.
KV now lets you attach arbitrary JSON metadata to each key/value pair at write time. Instead of sniffing content types at request time, you can compute them once during upload and store them alongside the value:
await contents.put(“index.html”, someHtmlContent, {“Content-Type”: “text/html”});
await contents.put(“index.css”, someCssContent, {“Content-Type”: “text/css”});
await contents.put(“index.js”, someJsContent, {“Content-Type”: “text/javascript”});The detection logic — whether you base it on the file extension, libmagic-style content inspection, or something custom — then lives in your upload tooling rather than in every worker invocation. Workers stay light, and request-time processing only has to read the stored answer.
Reading that information back is done through getWithMetadata(). The value it returns includes a metadata object, so metadata["Content-Type"] gives you the stored "text/javascript" directly. List operations also surface the metadata, and the arbitrary JSON flexibility means the field isn’t limited to content types — forum users have already eyed it for etags.
A second datacenter for the long tail
KV’s architecture balances global read performance against the cost of writes. Popular values are cached in every Cloudflare data center, but infrequently read data — and every write and delete — still goes back to a central source of truth. That single store was located in the US, so write latency depended heavily on where the write originated. European and Asian requests paid the round trip across the Atlantic.
That has changed. Cloudflare has brought a second source of truth online in Europe. The two stores coordinate with each other to keep data consistent, but writes originating from Europe — or regions closer to Europe than to the US — no longer need to travel all the way to America to commit.
The latency improvement is visible in internal product traffic, which shows a sharp drop in response times at the moment the second store went live:
Across all customer workloads, the same effect shows up as a dramatically shortened long tail:
The company notes the expected speedup depends on your specific workload, but the aggregate graphs make the direction of the change clear. More work is still under wraps at the distributed data team, but these two changes are available to try now.
