Cloudflare Workers KV Instant Explained: 177× Faster Reads, Pricing, Limits, and Setup

Key Takeaways

• Workers KV Instant is a new Quicksilver v2-powered mode of Cloudflare Workers KV. Announced on October 1, 2026, it remains in private beta as of October 14, 2026.
• Cloudflare reports 1.62 ms p99 read latency, compared with 287 ms for all classic KV reads. That represents approximately 177× lower tail latency in the published benchmark. Comparing cached classic reads (160 ms) gives approximately 99×.
• Instant writes propagate to Cloudflare's 300-plus edge locations in 107 ms at the median, 181 ms at p95, and 256 ms at p99, according to Cloudflare's measurements.
• Reads cost $0.20 per million keys requested, but every put, delete, or list operation costs $0.10, while storage costs $100 per MB-month.
• Each Instant namespace is limited to 1 MB of storage, 10,000 keys, and one write per namespace per second.
• The ideal workload is small, frequently read global configuration. Instant is not designed to replace transactional databases, object storage, or frequently updated application state.

What Is Cloudflare Workers KV Instant?

Cloudflare Workers KV Instant is a new storage mode that brings Cloudflare's internal Quicksilver global configuration distribution system to the familiar Workers KV interface.

Cloudflare introduced the product on October 1, 2026, in its official announcement, Introducing Workers KV Instant — powered by Quicksilver.

The service uses Quicksilver v2, an infrastructure system Cloudflare developed to distribute configuration rapidly across its global network. Instead of waiting for regional cache expiration or cold reads to retrieve updated values, Instant proactively propagates changes to edge locations.

The result is a specialized key-value service optimized for applications that need to read small configuration values on virtually every request.

Typical examples include:

• Global feature flags that enable or disable application functionality.
• Emergency kill switches for problematic integrations.
• Application maintenance and product-launch settings.
• Traffic-routing rules and upstream API failover configuration.
• Small configuration documents shared across multiple Workers.
• Coordinated application settings that need rapid global propagation.

Workers KV Instant is not an automatic upgrade to existing Workers KV namespaces. Developers must explicitly create a namespace in Instant mode.

As of October 14, 2026, it remains available through a private-beta application. Cloudflare has not announced a confirmed general-availability date in its launch materials.

Workers KV Instant Benchmarks: Is It Really 177× Faster?

The performance claim comes from Cloudflare's own measurements comparing Instant with classic Workers KV.

The write-replication measurements are not directly equivalent. Instant measures replication to all edge locations, while classic KV measures replication to required storage backends. Cloudflare also reports that its classic measurements lack sub-second precision.

Understanding the 177× Performance Claim

The headline ratio is calculated as follows:

Classic KV p99 read latency = 287 ms
KV Instant p99 read latency  = 1.62 ms

287 / 1.62 = 177.16

Approximate reduction factor = 177×

The calculation is valid for the published all-read p99 measurements.

However, comparing Instant against classic KV's cached-read p99 produces a different result:

160 / 1.62 = 98.77

Approximate reduction factor = 99×

This distinction explains why Cloudflare generally describes Instant as delivering approximately 100× faster reads, even though the all-read comparison produces a larger ratio.

What Does p99 Actually Mean?

P99 latency is the threshold below which 99% of measured operations complete.

For Cloudflare's reported Instant result, 99% of measured reads completed within approximately 1.62 milliseconds.

P99 is particularly important for globally distributed applications because a small fraction of slow storage requests can disproportionately affect users in distant geographic regions or requests that encounter cold caches.

However, these figures represent vendor-reported storage-operation measurements, not independently reproduced benchmarks.

They do not mean that a complete website, API request, or application will become 177 times faster.

A real request may also include:

• Network transit between a visitor and Cloudflare.
• Worker execution and middleware processing.
• Authentication or session validation.
• Database operations and external API calls.
• HTML generation and response transmission.
• Browser rendering and JavaScript execution.

The performance gain depends on whether the KV lookup is a significant part of the request's critical path.

How Quicksilver v2 Works

The fundamental improvement is architectural rather than a simple increase in hardware performance.

Classic Workers KV: Cache-Driven Distribution

Classic Workers KV uses distributed caching and storage infrastructure.

When a Worker requests a key, Cloudflare attempts to retrieve it through its caching hierarchy. Frequently accessed values benefit from caching, while a cold read may require communication with another caching or storage tier.

This architecture is cost-effective for large, read-heavy datasets, but it introduces two important trade-offs:

1. Cold reads can be substantially slower than cached reads.
2. An updated value may not immediately replace cached copies in every geographic location.

Cloudflare reduced classic Workers KV's minimum configurable cacheTtl from 60 seconds to 30 seconds in January 2026.

That improvement offers finer control over cache freshness, but it does not turn classic KV into a globally synchronized configuration service.

Workers KV Instant: Proactive Global Propagation

KV Instant takes a different approach.

When an application updates a configuration value, Quicksilver distributes that change throughout Cloudflare's network instead of relying on individual locations to discover updates after cache expiration.

This design reduces cold-read penalties and improves the speed at which configuration changes become visible globally.

The underlying Quicksilver v2 architecture includes multiple storage and caching layers, described in Cloudflare's engineering deep dive:

• Local server caches provide fast access to frequently requested values.
• Data-center-level caches allow servers to share cached configuration data.
• Full replicas retain larger portions of the distributed dataset.
• Relay and prefetch mechanisms help distribute updates and reduce expensive remote retrievals.

This architecture avoids requiring every server to store a complete copy of Cloudflare's entire internal configuration database.

In July 2025, Cloudflare reported that its internal Quicksilver infrastructure contained more than five billion key-value pairs, approximately 1.6 TB of data, and served over three billion key lookups per second globally.

Those figures describe the internal Quicksilver system, not the storage capacity available to an individual KV Instant namespace.

Fast Replication Is Not Strong Consistency

One critical limitation must be understood before adopting Instant for production systems.

A reported p99 propagation time of 256 milliseconds does not mean every update is guaranteed to become visible everywhere within exactly 256 milliseconds.

It also does not guarantee that multiple keys are updated atomically across all regions.

Applications requiring coordinated transactions, financial correctness, inventory reservations, or strongly synchronized mutable state should use a storage system designed for those requirements.

Workers KV Instant vs. Classic KV: Complete Comparison

Although Instant retains the familiar KV API, several important behavioral differences remain.

Cloudflare states that getWithMetadata() returns null in Instant mode because metadata is unsupported. Passing metadata through put() is also unsupported.

Additionally, list() returns all matching keys without pagination. Code that expects pagination cursors must be adapted.

The biggest operational difference is the write-rate restriction.

Classic KV restricts updates to the same key to one per second. Instant applies its restriction to the entire namespace.

Updating two unrelated keys within one second can therefore encounter a rate limit.

This restriction is manageable for infrequently changed configuration, but problematic for applications that continuously modify data.

Workers KV Instant Pricing in 2026

Cloudflare has published a distinct pricing model for Instant, making its intended workload unusually clear.

The figures come from Cloudflare's official Instant announcement and classic KV pricing documentation.

Why Instant Reads Are Cheaper

Cloudflare prices Instant reads at $0.20 per million requested keys, compared with the classic KV overage rate of $0.50.

That represents a 60% lower read unit price.

The lower rate is particularly attractive for globally distributed applications that read a small number of configuration values on every request.

For example, an application performing 100 million single-key reads would incur approximately $20 in Instant read charges at the published unit rate.

However, comparing read prices alone produces an incomplete economic picture.

Why Instant Writes Are Dramatically More Expensive

Instant's Class A operations include put(), delete(), and list().

Each operation costs $0.10.

That means:

• 10 writes cost $1.
• 100 writes cost $10.
• 1,000 writes cost $100.
• 10,000 writes cost $1,000.
• One million writes would cost $100,000 at the published rate.

At their published unit prices, an Instant key write is approximately 20,000 times more expensive than a classic KV key write before accounting for included usage.

Instant also charges $100 per MB-month of stored data.

This is why KV Instant should not be selected as a cheaper replacement for classic KV without examining the actual read/write ratio and storage footprint.

Classic KV includes usage allowances on Workers Free and Paid plans. Whether particular allowances or beta-specific terms apply to Instant must be confirmed through the account's billing arrangements.

Workers KV Instant Monthly Cost Calculator

The approximate cost formula is:

Monthly cost =
  (Read keys / 1,000,000 × $0.20)
  + (Writes + Deletes + Lists) × $0.10
  + (Stored MB × $100)

This excludes separate Workers execution charges, applicable allowances, taxes, and other account-specific adjustments.

Cloudflare bills bulk reads according to the number of keys requested, not simply the number of get() calls.

Example Monthly Costs

These are illustrative calculations using announced rates rather than observed customer invoices. Storage amounts are assumed to remain approximately constant throughout the month.

The Hidden Break-Even Point

At published unit prices, moving one million reads from classic KV to Instant saves $0.30 in read costs.

A single Instant write costs $0.10.

Therefore, approximately 333,333 reads are required to offset one Instant write through the difference in read prices alone.

Meanwhile, storing just 0.01 MB in Instant adds approximately $1 per month, requiring another 3.33 million reads to offset that cost through the lower read rate.

This comparison excludes classic KV's included usage and the operational value of lower latency.

The conclusion is straightforward: KV Instant is primarily a performance and propagation product, not automatically a cost-saving product.

Important Workers KV Instant Limits

Cloudflare's limits documentation, updated October 8, 2026, specifies the following restrictions.

These restrictions should influence application architecture from the beginning.

For example, 10,000 meaningful configuration records may exceed the 1 MB storage ceiling before reaching the key-count limit.

A safer design reserves capacity for configuration versions, rollback settings, and emergency controls.

Related flags can also be stored together in a single JSON document. This reduces the number of write operations and allows related fields to change together at the document level.

It does not provide transactions across multiple documents or a globally atomic cutover.

Best Use Cases for Workers KV Instant

1. Global Feature Flags

Feature flags allow application functionality to be enabled or disabled without redeploying code.

For a globally distributed Worker, Instant makes it possible to read the latest propagated flag state at low latency on requests arriving from different geographic locations.

This is especially useful when the feature is changed only a few times per day but evaluated millions of times.

2. Emergency Kill Switches

Applications frequently integrate third-party services that can fail unexpectedly.

A small Instant configuration value can tell Workers to disable a problematic integration or switch to a fallback provider.

However, critical failover mechanisms must handle missing configuration and propagation delays safely.

3. Global Product Launches

A product launch may require changing a landing page or enabling a feature at a coordinated time.

Instant's rapid global propagation reduces the delay between updating the launch configuration and its visibility across Cloudflare's network.

Applications should still tolerate short periods in which different regions observe different configuration versions.

4. AI Model Provider Routing

An AI application can use a small configuration document to select its preferred inference provider.

For example, the configuration might identify whether the application should use its primary provider or a fallback provider.

The configuration can be read frequently while changing only when operational conditions justify a route update.

High-frequency health measurements should remain in an appropriate monitoring system rather than generating continuous Instant writes.

5. Multi-Site Configuration Management

Organizations managing multiple Workers applications can use Instant as a small global configuration plane.

Examples include maintenance mode, controlled releases, and global integration switches.

The actual content, user data, and analytics should continue living in storage services appropriate to their size and write frequency.

When Workers KV Instant Is the Wrong Choice

Instant is a poor fit for workloads involving frequent writes or large datasets.

Examples include:

• Game leaderboards and constantly changing player scores.
• User session state and activity logs.
• Payment balances and transaction records.
• Large game directories or product catalogs.
• Search indexes and historical keyword datasets.
• Rapidly changing inventory quantities.
• Analytics events and page-view counters.
• Images, uploaded files, and AI-generated media.

For these workloads, alternatives include D1, Durable Objects, R2, Analytics Engine, or classic Workers KV.

Tutorial: Create Workers KV Instant with Wrangler and Hono

The following example uses a small global configuration document in a Cloudflare Worker powered by Hono.

Prerequisite: The Cloudflare account must have private-beta access. The commands follow Cloudflare's current getting-started documentation.

Step 1: Create an Instant Namespace

Run:

npx wrangler@latest kv namespace create APP_CONFIG --experimental-mode instant

This explicitly creates a namespace in Instant mode.

Without the experimental mode flag, the standard namespace creation command creates a classic KV namespace.

Save the returned namespace ID for the Worker binding.

Step 2: Configure the Worker Binding

Add the binding to wrangler.jsonc, preserving any other existing project settings:

{
  "name": "instant-config-demo",
  "main": "src/index.ts",
  "compatibility_date": "2026-10-14",
  "kv_namespaces": [
    {
      "binding": "APP_CONFIG",
      "id": "YOUR_NAMESPACE_ID"
    }
  ]
}

The binding makes the namespace available as env.APP_CONFIG inside the Worker.

Use separate namespaces for staging and production to prevent accidental changes to live configuration.

Step 3: Write a Global Configuration Document

A compact JSON document can hold several related settings:

{
  "version": 1,
  "maintenance": false,
  "fallbackProvider": false
}

Write the configuration using Wrangler:

npx wrangler@latest kv key put --binding=APP_CONFIG 'global:flags' '{"version":1,"maintenance":false,"fallbackProvider":false}' --remote

The --remote flag directs the operation to the Cloudflare-hosted namespace instead of local development storage.

Grouping related settings into a single JSON value can reduce billable write operations and avoid hitting the namespace-wide write-rate limit when several flags need to change together.

Step 4: Install Hono

If Hono is not already installed, run:

npm install hono

Step 5: Read Instant Configuration in a Worker

Create src/index.ts:

import { Hono } from 'hono';

type Bindings = {
  APP_CONFIG: KVNamespace;
};

type Flags = {
  version: number;
  maintenance: boolean;
  fallbackProvider: boolean;
};

const app = new Hono<{ Bindings: Bindings }>();

app.get('/api/config', async (c) => {
  c.header('Cache-Control', 'no-store');

  try {
    const flags = await c.env.APP_CONFIG.get<Flags>(
      'global:flags',
      'json'
    );

    if (!flags || typeof flags.version !== 'number') {
      return c.json({ error: 'Configuration unavailable' }, 503);
    }

    return c.json({
      version: flags.version,
      maintenance: flags.maintenance === true,
      fallbackProvider: flags.fallbackProvider === true,
    });
  } catch {
    return c.json({ error: 'Configuration unavailable' }, 503);
  }
});

export default app;

The example returns a clear error if the configuration is missing or unreadable rather than silently enabling a potentially unsafe default.

A production application should validate the entire configuration schema and implement a fallback policy appropriate to its security and availability requirements.

Only nonsensitive configuration should be exposed through a public endpoint.

Step 6: Deploy the Worker

npx wrangler@latest deploy

Once deployed, the endpoint can read configuration through the Instant namespace binding.

Updates should be tested from multiple geographic regions before relying on the configuration for a time-sensitive production rollout.

Cloudflare also supports namespace creation through its REST API using mode: "instant", or through the Cloudflare CLI using --namespaceMode instant.

How to Migrate Existing Workers KV Applications

Migrating an existing application requires more than replacing its namespace binding.

A controlled migration should include the following steps.

1. Audit KV operations. Measure reads, writes, deletes, list requests, stored bytes, and p95/p99 read latency.
2. Identify appropriate configuration keys. Keep large datasets and frequently changing values in their existing storage services.
3. Check API compatibility. Remove assumptions about metadata and list pagination.
4. Create a dedicated Instant namespace. Existing classic namespaces are not automatically converted.
5. Migrate selected keys. Respect the namespace-wide write-rate restriction while seeding data.
6. Deploy a staging Worker. Validate configuration reads, malformed data, missing keys, and rollback behavior.
7. Measure global propagation. Update a versioned key and observe the time required for geographically distributed requests to see the new version.
8. Monitor costs. Track Class A operations, read volume, and stored capacity before expanding usage.

Infrastructure-as-Code systems also require attention. Changing a resource's namespace mode may replace the underlying resource rather than migrate its data.

Configuration tooling should not be assumed to copy key-value pairs automatically.

Seven Production Risks Developers Should Understand

1. Global Propagation Is Not a Transaction

A rapid replication p99 does not guarantee that every location changes state simultaneously.

Applications should tolerate brief differences between configuration versions observed in separate regions.

2. Frequent Writes Can Trigger Rate Limits

A monitoring system that rewrites a configuration value every time an upstream service changes health status can exceed one write per namespace per second.

Use a separate monitoring system and controlled update logic rather than treating Instant as a high-frequency operational event store.

3. List Operations Can Generate Unexpected Bills

At $0.10 per operation, repeatedly calling list() can become expensive.

For a 30-day month, listing once per minute creates approximately 43,200 calls and $4,320 in list charges at the published rate.

Normal request handlers should retrieve known keys directly rather than listing a namespace to discover them.

4. Downstream Caching Can Delay Updates

Even after Instant propagates a configuration change, another caching layer may continue serving an older response.

For example, an HTTP response cached for five minutes can remain stale despite the underlying KV update becoming available in a fraction of a second.

Developers must examine CDN cache behavior, application-level caches, and client-side caching separately.

5. Sensitive Configuration Requires Access Controls

KV Instant is not a substitute for secret management.

Credentials, private routing information, and security-sensitive configuration should not be exposed through an unauthenticated public endpoint.

Administrative write operations should be tightly restricted.

6. Faster KV Reads Do Not Guarantee Better SEO Rankings

Reducing KV latency may improve dynamic response time and Time to First Byte when KV access lies on the request's critical path.

However, Core Web Vitals depend on the full page experience.

For example, Largest Contentful Paint may still be dominated by images, rendering, JavaScript, or other network requests.

Real-user performance data and Cloudflare's request instrumentation provide better evidence than assuming infrastructure microbenchmarks translate directly into SEO improvements.

7. Beta Pricing and Availability Can Change

KV Instant remains a private-beta product as of October 14, 2026.

Developers should confirm current access requirements, account-specific pricing, included usage, and production suitability before committing critical workloads.

Workers KV Instant vs. D1, R2, and Durable Objects

Cloudflare offers several services that solve different storage and coordination problems.

This division is particularly useful for applications built entirely on Cloudflare Workers.

For example, a website network can use a small Instant namespace to control maintenance and feature rollouts while storing content in D1 and images in R2.

There is no advantage in placing a large game directory or search index into a 1 MB Instant namespace merely to gain fast configuration reads.

How to Benchmark KV Instant in Real Applications

Cloudflare's reported measurements provide a useful starting point, but real deployment decisions require workload-specific testing.

A meaningful experiment should separate three metrics.

KV Read Latency

Instrument the duration of get() calls.

Compare p50, p95, and p99 latency across representative geographic locations and equivalent classic KV workloads.

Document whether classic KV reads were cached or cold.

Global Configuration Propagation

Write a configuration document with an incrementing version number.

Record the completion time of the write, then poll from geographically distributed clients to observe when the new version becomes visible.

This measures application-observed propagation rather than Cloudflare's internal replication telemetry.

End-to-End Request Performance

Compare Worker response latency, dynamic TTFB, error rates, and relevant real-user performance metrics.

Include the impact of authentication, API calls, rendering, and downstream caching.

A useful evaluation should also calculate the total cost per million application requests, accounting for read operations, configuration changes, storage, and Worker execution.

October 15, 2026: A Separate Workers KV API Deadline

Cloudflare has announced that legacy Workers KV REST API routes under /accounts/{account_id}/workers/namespaces/ will stop working on October 15, 2026.

Integrations must migrate to /accounts/{account_id}/storage/kv/namespaces/.

The official deprecation notice states that the replacement endpoints accept equivalent request parameters and return equivalent response structures.

This deadline is separate from KV Instant's release and private-beta status.

It applies to integrations using the legacy API routes regardless of whether they intend to adopt Instant.

Frequently Asked Questions

Is Cloudflare Workers KV Instant available to everyone?

No. As of October 14, 2026, Instant remains in private beta. Developers must request access or work with their Cloudflare account team.

Does Workers KV Instant automatically replace classic KV?

No. Developers must explicitly create a namespace in Instant mode and migrate the selected data and bindings.

Is Workers KV Instant strongly consistent?

Cloudflare reports very fast global propagation, but those measurements do not establish a general strong-consistency guarantee or atomic multi-key transactions.

Is Workers KV Instant cheaper than classic KV?

Its published read price is lower, but writes, deletions, list requests, and storage are dramatically more expensive. Total cost depends on the workload and applicable billing allowances.

Does Instant support metadata?

No. Cloudflare states that metadata is unsupported and getWithMetadata() returns null in Instant mode.

Can Instant store thousands of keys?

The documented maximum is 10,000 key-value pairs, subject to the total 1 MB namespace storage limit. Applications may reach the storage ceiling before reaching 10,000 keys.

Does a bulk get() count as one billable read?

No. Instant charges Class B operations according to the number of keys requested, even when multiple keys are retrieved in a single call.

Can Workers KV Instant replace D1 or Durable Objects?

Not for relational queries, high-frequency mutations, transactions, or coordinated state. Instant is specifically optimized for small, globally distributed configuration.

How can developers apply for the beta?

The official Workers KV Instant beta page provides the application form. Developers should describe a concrete use case involving frequent reads and infrequent configuration updates.

Conclusion

Cloudflare Workers KV Instant introduces an important new option for global edge configuration, but it is not a universal replacement for Workers KV.

Its Quicksilver v2 foundation enables Cloudflare's reported 1.62 ms p99 read latency and 256 ms p99 global propagation, making it attractive for feature flags, emergency switches, and frequently accessed application settings.

The trade-offs are substantial: $0.10 per Class A operation, $100 per MB-month of storage, a 1 MB namespace limit, and one write per namespace per second.

For most production applications, the best architecture is a combination of services: KV Instant for a small configuration plane, classic KV for economical read-heavy data, D1 for relational records, Durable Objects for coordinated state, and R2 for larger objects.

The most useful first experiment is a single versioned configuration document used by a high-traffic Worker. Measure read latency, global propagation, failure handling, and complete monthly cost before expanding deployment.

Next step: Review the official Workers KV Instant announcement, confirm the current documented limits, and apply for private-beta access if rapid global configuration is valuable to the application.