Reference guide · cloudflare · Published 2026-08-16 · 3 min read
Cloudflare Workers storage KV vs R2 vs D1
Compare Cloudflare Workers KV, R2 and D1 for a Worker. Learn which store fits key-value, object and relational data, and how consistency shapes the choice.
- ·Three storage products
- ·How to decide
- ·Consistency matters
Three storage products
Cloudflare gives Workers three connected storage backends, each tuned for a different shape of data. Picking correctly removes most built-in pain.
- Workers KV is a global key-value store. It is eventual consistent: a write propagates across the network over roughly a minute, so a read can briefly return the previous value. It is built for read-heavy lookups of configuration, feature flags, metadata, or cached payloads, and one write per second per key is expected.
- R2 is S3-compatible object storage. It stores large, unstructured blobs such as images, video, archives or backups, with per-object consistency and no egress fees. You cannot query inside an object; you read and write whole keys.
- D1 is a serverless SQL database built on SQLite. It stores structured, relational data that needs SQL queries, joins or indexes, and offers read replicas. Single databases are capped around 10 GB, which suits relational data sets rather than bulk media.
- Durable Objects sit alongside these for strongly-consistent, per-entity coordination such as collaborative editing or rate-limit counters, though they are a distinct mechanism rather than a storage class in the same sense.
How to decide
Ask what shape the data takes and how stale it may be:
| Need | Product |
|---|---|
| A single value keyed by a string, read at high rate | KV |
| A file or blob, possibly large, read or written whole | R2 |
| Rows you filter, join or count with SQL | D1 |
| One mutable record many clients must agree on | Durable Objects |
Rule of thumb:
- Reaching for a value by a known key, tolerate minutes of propagation lag: KV.
- Storing an asset by path or filename: R2.
- Querying by several fields, updating a user record, or needing immediate read-back of a write: D1.
Consistency matters
The decision is really about consistency and query model more than storage space. A write-then-read-immediately pattern breaks on KV because propagation lags; moving that counter or user bio to D1 or a Durable Object gives strong consistency. A workload that only needs "give me this config, and slightly stale is fine" is a perfect KV fit and costs far less than forcing it into SQL.
Store bulk assets in R2 rather than squeezing them into KV values, and keep a KV value small and self-contained. Combine stores when a workflow needs both, for example an R2 object whose metadata lives in D1 and a KV flag that tells the Worker where to find it. Understand the Worker request lifecycle and how one store can back an origin pool before wiring a storage layer into a load-balanced setup, and start from the Worker basics if the request model is new.