Choosing KV, D1, R2, or Durable Objects
Choose Cloudflare storage by data shape, consistency, object size, and coordination needs.
Edited and verified by Orange Book Editorial Team ·
Ask four questions first
- Is the data key-value, relational, a file object, or state needing a coordinator?
- Must every location observe a write immediately?
- Does a read fetch one small value, rows, or a large object?
- Must concurrent requests be ordered by one stateful instance?
| Product | Good fit | Do not treat it as |
|---|---|---|
| Workers KV | Read-heavy, infrequently updated configuration where eventual consistency is acceptable | A globally consistent counter |
| D1 | Relational data, SQL queries, indexes, and constraints | A large-file store or global lock |
| R2 | Images, backups, model files, and other objects | A low-latency relational query engine |
| Durable Objects | Strongly consistent state and coordination per object | A casual replacement for every database |
Current free-tier fact snapshot (verify before release)
Cloudflare can change plans and limits; reopen the primary source before implementation.
| Product / plan | Current fact | Scope and caveat |
|---|---|---|
| Workers KVWorkers Free | KV reads100,000 reads / day | A daily Free-plan allowance; operations fail after it is exhausted. Verified · Source updated Primary source |
| Workers KVWorkers Free | KV storage1 GB / account | Both the Free-plan account and namespace limit are 1 GB. Verified · Source updated Primary source |
| D1Workers Free | D1 database size500 MB / database | Each Free-plan database is 500 MB; account storage is 5 GB total. Verified · Source updated Primary source |
| R2Standard free tier | R2 Standard storage10 GB-month / month | The free tier applies to Standard, not Infrequent Access. Verified · Source updated Primary source |
Composition often beats a forced single choice
A media app can keep metadata in D1, originals in R2, and popular public configuration in KV. Add a Durable Object only when a room, document, or session truly requires single-object coordination. Every extra store adds permissions, migration, backup, and diagnosis work.
Validate the decision
- Write one scenario where a stale read is unacceptable; KV should not be its source of truth.
- State maximum object size and query shape; avoid putting binaries in relational rows.
- Simulate two concurrent writes and decide whether a database constraint or coordinator is required.
- Open each current Pricing and Limits page and estimate from the access pattern, not capacity alone.
Continue across platforms
After choosing the internal storage shape, test the external platform boundary: use R2 vs S3, OSS, and B2 for files and public delivery, and D1 vs Supabase and Neon for relational data. Both start with runtime and total cost instead of treating a free tier as an architecture guarantee.
If the requirement is specifically a cache, session store, rate limiter, leaderboard, or Stream shared across application instances, external Valkey becomes a candidate. Read Valkey for beginners, then compare its consistency, network, and operational cost with KV, the Cache API, and Durable Objects. The related technology guide network provides the complete set of topic-site entry points.
Primary sources
Did this page help you complete your goal?
Beta feedback is generated in this browser and is never uploaded automatically.
Workers and Pages vs Vercel, Railway, and Render
Compare Cloudflare Workers, Pages, Vercel, Railway, and Render across runtime, static hosting, Next.js DX, containers, background jobs, persistence, and billing.
R2 vs S3, OSS, and B2: choosing cost-efficient object storage
Compare R2, Amazon S3, Alibaba Cloud OSS, and Backblaze B2 across storage, requests, public egress, ecosystem, and region—and learn when R2 is cost-efficient.