Skip to content

CLOUDFLARE 2026-10-01 Tier 1

Read original ↗

Introducing Workers KV Instant - powered by Quicksilver

Summary

Cloudflare launched Workers KV Instant (private beta, 2026-10-01), a new mode for Workers KV that exposes the same KV API (get/put/list/delete) but powers it with Quicksilver (specifically Quicksilver v2), Cloudflare's internal globally-replicated key-value store that "nearly every request to Cloudflare looks up at least one key in." After years of customer requests to expose Quicksilver, KV Instant makes it available: 100× faster p99 reads (<2 ms vs classic KV's 287 ms) and immediate global updates with no need to wait for a cache TTL to expire — purpose-built for infrequently-updated application configuration data on the hot path (flags, settings), the exact workload Cloudflare uses Quicksilver for itself. It is deliberately not for every workload: storage and write (Class A) operations are far more expensive than classic KV, and it caps namespaces at 1 MB / 10,000 keys with a one-write-per-namespace-per-second limit — the article frames KV and KV Instant as two modes for two different data/access patterns, not a replacement.

Key takeaways

  1. Same API, different engine — pick the mode at namespace creation. KV Instant uses the familiar Workers KV API; the only way to opt in is to pass "mode": "instant" when creating the namespace. "Most binding operations are compatible with the Workers KV classic equivalents." (Source: sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver)

  2. 100× faster p99 reads, 20× faster writes. Instant reads resolve in 1.62 ms at p99 (p95 in microseconds); classic KV is 160 ms p99 cached / 287 ms p99 all. Writes replicate to all 300+ edge locations at median 107 ms / p95 181 ms / p99 256 ms; classic KV write replication is <1 s typical / 4.38 s p99 (to all required storage backends, no sub-second fidelity). (Source: sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver)

  3. It is literally Quicksilver, exposed. "KV Instant is powered by Quicksilver v2, a key-value store developed internally by Cloudflare to enable fast global replication and low-latency access on a planet scale." This is the first time Cloudflare has made Quicksilver available to customers after "people have asked us for years." (Source: sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver)

  4. The target workload is config on the hot path. "These high-performance characteristics … make it ideal for reading data in the hot path of your applications, especially flags and settings that should be available globally nearly instantly after they've been written." The worked example is a launch-day feature flag read on every request and flipped at a keynote moment — read new-product-launched from env.APP_CONFIG with near-zero latency and no TTL wait. (Source: sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver)

  5. Writes pass through a single system of record. "Because writes must pass through a single system of record, KV Instant also restricts write frequency to one write per namespace per second." This is the leader/follower shape — a single authoritative writer fans out to the global read replicas — which is what buys the strictly-ordered, instantly-visible updates (and what forces the 1-write/namespace/s ceiling). Classic KV's limit is per key; Instant's is per namespace, which "makes it easier for you to reason about update order in your application." (Source: sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver)

  6. The cost model is deliberately inverted vs classic KV. Reads are 60% cheaper ($0.20/M vs $0.50/M), but storage is $100 per MB-month (vs $0.50/GB-month) and Class A writes are $0.10 per operation (vs $5.00/M). "If you need to store large amounts of data, or update it frequently, Workers KV continues to be a great fit. Each mode is designed for a very different type of data and access pattern." (Source: sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver)

  7. API differences are the price of the Quicksilver engine. Three concrete deltas vs classic KV: (a) must declare "mode": "instant" at namespace creation; (b) no metadata — getWithMetadata always returns null, put can't carry metadata; (c) list returns ALL matching keys with no pagination (a single list is one Class A op regardless of key count, feasible because a namespace is capped at 10,000 keys / 1 MB). Multi-key get(["a","b","c"]) bills one Class B op per requested key, same as three separate gets. (Source: sources/2026-10-01-cloudflare-introducing-workers-kv-instant-powered-by-quicksilver)

Systems

  • Workers KV — the product surface. KV Instant is a mode of Workers KV, not a separate product; same API, Quicksilver engine.
  • Quicksilver (v2) — the internal globally-replicated KV store now exposed through KV Instant. "Nearly every request to Cloudflare looks up at least one key in Quicksilver."
  • Workers — KV Instant is accessed as a Workers binding (env.APP_CONFIG.get(...)), same as classic KV.

Concepts

  • concepts/eventual-consistency — classic KV is eventually consistent (TTL-bounded staleness); KV Instant collapses the convergence window to ~250 ms p99 to all edge locations by replicating from a single system of record, closing the staleness gap that made classic KV unfit for hot-path config reads.
  • concepts/hot-path — the explicit design target: reads "in the hot path of your applications," on every request, at any scale.
  • concepts/latency-critical-vs-latency-tolerant-workload — KV vs KV Instant is a per-namespace realization of this distinction inside one product: latency-critical config (Instant) vs latency-tolerant / large / frequently- written data (classic KV), each with an opposite cost frontier.
  • concepts/strong-consistency — not claimed (reads are from replicas), but the single-system-of-record write path plus ~250 ms global fan-out gives near-immediate read-after-write in practice for config, which is why TTLs are gone.
  • concepts/read-amplification — the workload is read-heavy by design (reads 60% cheaper, writes expensive + rate-limited); the whole cost model assumes a tiny write rate amplified into enormous read volume.
  • concepts/feature-flag — the canonical use case (launch-day flag read on every request, flipped instantly).

Replication shape

  • concepts/leader-follower-replication — "writes must pass through a single system of record" then replicate to 300+ read locations: the classic single-leader / many-follower shape, here as the mechanism behind instant global visibility and the per-namespace write-rate ceiling.

Operational numbers

Metric KV Instant Classic KV
p99 reads (all) 1.62 ms 287 ms
p99 reads (cached) N/A 160 ms
p95 reads microseconds —
Median write replication 107 ms (to all 300+ edge locations) <1 s
p95 write replication 181 ms <1 s
p99 write replication 256 ms 4.38 s
Reads (Class B) $0.20 / M keys $0.50 / M
Writes/list (Class A) $0.10 / operation $5.00 / M
Storage $100 / MB-month $0.50 / GB-month
Max value / namespace 1 MB total; 10,000 keys —
Max key size 300 bytes —
Write-rate limit 1 write / namespace / second 1 write / key / second

Replication reaches over 300 edge locations as of publication. Launch stage: private beta (sign-up link in post).

Caveats

  • Launch post, Cloudflare's own numbers — latency/replication figures are Cloudflare-reported, not independently benchmarked; private beta.
  • Not a general-purpose store — 1 MB / 10,000-key namespace cap, 1-write/namespace/s, no metadata, expensive storage & writes. For large or write-heavy data, classic KV remains the recommended mode. The post is explicit that these are "two modes … for a very different type of data and access pattern."
  • No pagination on list — returns all matching keys in one page; only tractable because of the 10,000-key cap.
  • Quicksilver v2 internals not re-explained — the post links the earlier Quicksilver v2 series rather than re-deriving the replication design here.

Source

Last updated · 766 distilled / 2,225 read