Workers KV Instant: Sub-2ms Reads, Powered by Quicksilver

Classic Workers KV has a cold-read problem developers have quietly worked around for years. That first read at any new edge location costs 200–300ms while the cache warms up. Feature flag updates can take up to 60 seconds to propagate globally. The usual workarounds — Durable Objects for overkill consistency, external Redis that defeats the whole edge premise — are hacks. Cloudflare launched Workers KV Instant on October 1 to fix this properly: sub-2ms reads, 250ms global write propagation, powered by the same internal key-value system that runs Cloudflare’s own firewall rules.

The Numbers First

KV Instant delivers p99 read latency of 1.62ms versus 287ms for classic KV — a 177x improvement at that percentile. Write propagation drops from 4.38 seconds (p99) to 256ms. Reads also cost 60% less: $0.20 per million versus $0.50 for classic mode. Those are not incremental gains. The cold-read penalty that made classic KV unreliable for hot-path operations is gone.

Metric	KV Instant	Classic KV
p99 read latency	1.62 ms	287 ms
p99 write replication	256 ms	4.38 s
p95 write replication	181 ms	<1 s
Read cost per million	$0.20	$0.50

What You Are Actually Getting: Quicksilver

The performance comes from Quicksilver, Cloudflare’s internal key-value store built in 2018 to replace Kyoto Tycoon. Nearly every request to Cloudflare’s network looks up at least one key in Quicksilver — routing rules, SSL certificates, firewall configurations, rate limiting thresholds. It was purpose-built for one job: propagate configuration data to 300+ edge locations as fast as possible.

Classic Workers KV uses pull-on-read caching: data lives in central stores and gets cached at edge locations after first access. Quicksilver uses push-on-write replication: when you write, it immediately propagates across the global mesh. That architectural difference is what produces the 17x faster write replication. Workers KV Instant gives your application the same infrastructure Cloudflare trusts for its own operations.

The Limitations Are Real

KV Instant is not a general-purpose KV replacement. The constraints are significant and by design:

• 1MB namespace ceiling, 10,000 key-value pairs max. This is a config layer, not a database.
• No metadata support. getWithMetadata() returns null. If you rely on metadata, this is a blocker.
• No pagination. list() returns all matching keys at once — fine for 500 config keys, not for 50,000.
• 1 write per namespace per second. Classic KV allows 1 write per key per second, which is less restrictive for multi-key workloads.
• Private beta. Access requires signup; not yet generally available.

The storage pricing also deserves a closer look: $100 per MB per month sounds alarming until you remember the 1MB ceiling. A namespace with 10,000 keys averaging 100 bytes each hits that ceiling at $100/month. For a config-and-flags use case with millions of reads per day at $0.20/million, the read cost dominates and is cheaper than classic KV. For anything else, these limits are disqualifying.

When to Use It

KV Instant has one job and it does it well: infrequently-written, globally-read configuration data that must propagate fast. That covers a surprisingly large class of real applications:

• Feature flags and A/B test toggles
• Application configuration (API endpoints, thresholds, rate limits)
• Maintenance mode or outage kill switches
• Canary deployment controls
• Per-tenant settings that need global propagation in seconds

Do not use it for counters, leaderboards, inventory, or anything with concurrent writes. The 1 write per namespace per second limit will bite you, and KV Instant provides eventual consistency — not transactional guarantees. For that, Durable Objects remain the right tool.

Migrating an Existing Namespace

KV Instant uses the same API as classic KV — get(), put(), list(), delete() — so migration is mostly a namespace swap. The checklist before switching:

1. Remove any getWithMetadata() calls — they will silently return null
2. Verify your data fits within 1MB and 10,000 keys
3. Confirm your write rate is well below 1 write per namespace per second
4. Create a new namespace with the --experimental-mode instant flag
5. Backfill keys, then update the binding in wrangler.toml

wrangler kv namespace create MY_CONFIG --experimental-mode instant

The resulting namespace ID goes into your standard binding. No other wrangler.toml changes required. The Worker code reads identically either way:

async fetch(request, env, ctx) {
  const launched = (await env.APP_CONFIG.get("new-product-launched")) === "true";
  if (launched) {
    return new Response("Welcome to the launch!");
  }
  return new Response("Coming soon...");
}

Worth It for the Right Workload

The 1MB ceiling and private beta status are the only real friction points. Everything else — the performance, the pricing, the API compatibility — is straightforwardly better for the use case KV Instant targets. If you are currently using classic Workers KV for feature flags or application config and accepting the 60-second propagation delay and cold-read latency as unavoidable, they are not. Sign up for the beta via Cloudflare’s KV documentation and test on a non-critical namespace first.