Cloudflare Workers KV Limits 2026: What Hit, What Bit, and the Cheaper Drop-In

If you're on the Cloudflare Workers KV free tier in May 2026, here are the numbers that actually matter, and the one you'll hit first.

The 2026 free tier, in five rows

| Operation | Free per day | What happens at the cap | |---|---:|---| | Reads | 100,000 | Further reads fail with an error | | Writes | 1,000 | Further writes fail with an error | | Deletes | 1,000 | Same | | List operations | 1,000 | Same | | Total storage | 1 GB | Writes start rejecting |

All counters reset at 00:00 UTC. The caps are hard. You don't get throttled or queued, you get a failed response.

The one you'll actually hit

For most workloads on KV, it's not reads. 100,000 reads a day is genuinely a lot — enough for a small SaaS dashboard or a moderately busy edge cache. The number that surprises people is 1,000 writes.

Think about what 1,000 writes actually is. A small webhook that fires once a minute on average burns 1,440. A counter that increments on each page view of a 5K-visitor day blows the budget by lunch. A nightly batch job that updates 1,200 cached records doesn't fit at all.

The list-operations cap (1,000) gets people too if they're using KV for prefix-scan patterns like "list all sessions" or "list all keys for this user". One unfortunate page-load pattern can chew through the quota in an afternoon.

What changed in 2026

The current limits have been stable through 2026. Earlier free tiers were more generous — older blog posts reference 1M reads/day. That was scaled down. The 100K/1K shape is what you should plan against now.

The "drop-in cheaper" pitch

This is where we're a bit biased, so feel free to skim. BaseKV is the alternative we built for this exact shape: small-to-mid workloads where the write count creeps past 1,000/day and the bill suddenly matters.

• Flat monthly pricing instead of per-operation metering
• No surprise cap that fails operations mid-day
• Disk-first, not edge-first (latency is fine for most apps, the cost is the win)
• Same HTTP-shaped key/value API so the migration is mostly a base URL swap

If your app is genuinely edge-latency-critical (game state, ad bidding, anything where 10ms vs 50ms matters), stay on Workers KV and budget for the Standard plan. If your app is a webhook receiver, a job queue, a config store, or a session cache where 50ms is fine, BaseKV is the cheaper shape.

When Workers KV is the right answer anyway

Three cases where staying on KV is correct even after you cross the free tier:

1. You're already deep in the Workers ecosystem. If your code runs in Workers, KV is the path of least resistance and the egress between Worker and KV is included. Don't optimize for a $5/month saving at the cost of a refactor.
2. You need genuine edge-distributed reads. KV replicates to every Cloudflare edge. If your read pattern is "global users hit a static-ish config", that's KV's wheelhouse and we won't pretend otherwise.
3. You're going to outgrow 1GB anyway. KV's Standard plan scales smoothly past 1GB. Picking an alternative that caps at 10GB just to dodge the free tier is a false economy if you're planning for real growth.

The takeaway

The 100K-read / 1K-write asymmetry is the thing to remember. If your app's read-write ratio is below 100:1, you'll hit the write cap before you hit the read cap, no matter how much you optimize. That's the case for picking an alternative early — or budgeting for the Standard plan from day one.

We built BaseKV for the apps that fall into that asymmetry. If yours doesn't, KV is fine.

---

Related: Cheap DynamoDB Alternative for Side Projects, Vercel KV Alternative Pricing, Persistent Key-Value Storage.