Cloud Parts

Workers KV

Cloudflare’s global key-value store that keeps data in a few central stores and caches it in the data centers where it is read, so reads are fast and writes take up to a minute to show up everywhere.

What it is
Key-value stores
Used for
Caching
Type
Commercial product
Made by
Cloudflare, Inc.
License
Proprietary
Facts checked
12 October 2026
Website

What it is

A write goes to a small number of central data stores; it is not pushed to every location. The first read of a key in a location misses the local cache and walks up a regional tier, then a central tier, then the central stores. After that, reads in that location come straight from Cloudflare’s cache, and KV refreshes popular values in the background before they expire. Each cached value lives for cacheTtl seconds (60 by default, 30 at minimum), and “key not found” answers are cached too. So a change is usually visible at once where it was made, but can take 60 seconds or more to reach other locations, and if two writes hit the same key the last one wins.

That makes KV a read-heavy store: configuration, feature flags, allow lists, redirects, static assets and user preferences that change rarely and are read on every request. A namespace has no limit on keys; a key can be 512 bytes, a value 25 MiB, with up to 1,024 bytes of metadata and an optional expiry. One key can be written once per second, and faster writes get HTTP 429. The Workers Paid plan includes 10 million reads and 1 million writes, deletes and lists a month, then charges $0.50 per million reads, $5.00 per million writes and $0.50 per GB-month stored, with no egress fees. In October 2026 Cloudflare put Workers KV Instant into private beta: a mode with the same API, backed by its internal Quicksilver store, that replicates 99% of writes to every location in about 250 ms, for namespaces of up to 1 MB.

Why teams pick it

  • Reads of hot keys come from the cache in the data center running the Worker; Cloudflare reported a 12 ms median read when KV became generally available
  • Effectively unlimited keys and storage on the paid plan, values up to 25 MiB, and no egress fees
  • A binding with get(), put(), delete() and list(), plus per-key expiry and metadata, so a Worker needs no client library or credentials
  • Cheap reads ($0.50 per million) suit data read far more often than it is written

Watch out for

  • Eventually consistent: another location can serve the old value (or a cached “not found”) for 60 seconds or more after a write, so it is wrong for balances, counters or locks
  • One write per second per key; concurrent writes to a key silently overwrite each other, and there are no transactions or atomic operations
  • The first read of a key in a location is a cold read from the central stores and is much slower than a cached one
  • Writes cost ten times as much as reads ($5.00 per million), and on the Free plan an account gets only 1,000 writes a day

Alternatives

What all key-value stores have in common →
Amazon DynamoDBAWSAWS’s serverless key-value and document database, with single-digit-millisecond reads at any size.Amazon ElastiCacheAWSAWS’s managed Valkey, Redis OSS and Memcached, as node-based clusters or a serverless cache.Amazon MemoryDBAWSA Valkey- and Redis-compatible database that keeps everything in memory but loses no acknowledged write.FoundationDBOpen sourceAn ordered, distributed key-value store with strictly serializable ACID transactions across the whole cluster, built as a small core that other databases are layered on.MemcachedOpen sourceA simple, multithreaded in-memory key-value cache; clients hash keys across independent servers.RedisOpen sourceAn in-memory data-structure server: the default cache, and also queues, counters and leaderboards.RocksDBOpen sourceThe embedded key-value engine Facebook forked from LevelDB: an LSM tree in a C++ library that many databases and stream processors use as their storage layer.ValkeyOpen sourceThe Linux Foundation’s BSD-licensed fork of Redis 7.2.4: an in-memory key-value server that Redis clients can talk to unchanged.

How it fits with other technologies

Read a flag on every request, update it rarely · ts

// wrangler.jsonc: "kv_namespaces": [{ "binding": "CONFIG", "id": "<NAMESPACE_ID>" }]
export default {
  async fetch(request, env): Promise<Response> {
    if (request.method === "PUT") {
      // at most one write per second to the same key
      await env.CONFIG.put("banner", await request.text(), {
        metadata: { updatedBy: "admin" },
      });
      return new Response("saved", { status: 201 });
    }

    // cached in this location for 5 minutes; other locations may lag a write
    const banner = await env.CONFIG.get("banner", { cacheTtl: 300 });
    return new Response(banner ?? "no banner");
  },
} satisfies ExportedHandler<{ CONFIG: KVNamespace }>;

See it in a real stack

No architecture uses Workers KV yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2018–2026

Cloudflare Workers ran JavaScript in every Cloudflare data center, but at first they had nowhere to keep data. Customers who wanted to handle, say, billions of redirects had to hard-code them into a script that had to fit in 1 MB and redeploy it for every change.

On 28 September 2018 John Graham-Cumming announced Workers KV as a native key-value store for Workers, with values written through the Cloudflare API and available “within seconds” at Cloudflare’s 150+ locations. It became generally available on 21 May 2019. The GA post explained the trade-off in CAP terms: KV picks availability and partition tolerance, so reads are fast (a 12 ms median) and the last writer eventually wins everywhere in under 60 seconds.

The original design stored every value in two third-party object stores and raced reads against both. Cloudflare later moved to a single provider, and on 12 June 2025 that provider’s outage made a large share of KV requests fail for over two hours, taking down Access logins, Gateway and WARP with it. Cloudflare then moved KV onto its own sharded database clusters, the same system behind R2 and Durable Objects, and in October 2026 previewed KV Instant, a mode built on its internal Quicksilver store.

Why it’s built this way

Eventual consistency in exchange for cached reads
The GA post framed it as the “Matthew question”: are you fine with someone occasionally acting on a stale value? For redirects, config and auth tokens the answer is yes, and that buys reads served from the local cache.
Central stores plus pull-through caching, not full replication
Writes land in a few central stores and each location caches only what it reads, so each location holds only the keys its users actually read, at the cost of slow cold reads. KV later grew to hundreds of billions of keys.
Moving storage onto Cloudflare’s own infrastructure
After the June 2025 outage, Cloudflare said KV’s workload of mostly tiny values (a median of 288 bytes) suited a sharded, three-way replicated database better than object storage, and that it should not depend on a third party.

Timeline

  1. 2018

    Workers KV announced on 28 September

  2. 2019

    Generally available on 21 May

  3. 2025

    A third-party storage outage on 12 June takes KV and dependent Cloudflare services down for over two hours

  4. 2025

    KV moves onto Cloudflare-run storage, announced 8 August

  5. 2026

    Workers KV Instant, backed by Quicksilver, enters private beta on 1 October

Sources7 · facts checked 12 October 2026

Improve this page on GitHub