Workers KV vs Durable Objects vs D1: Pricing a Real Counter

Earlier today I measured my Workers KV click counter losing nine of ten concurrent increments with zero errors, and that post ended on a promissory note: when this tracker outgrows KV, move the counters to a Durable Object or to D1, in one migration. This post is the work behind that sentence. I read the pricing pages for all three products on the same day, August 4, 2026, and priced them against the one workload I can describe honestly, the click tracker behind this blog's affiliate links. The short version: the free write ceilings differ by 100x, the two SQLite-backed options price rows identically, and the deciding factor is which meters exist at all.

The workload being priced

My tracker runs entirely on Workers KV. A visitor who reads one post and clicks one affiliate link costs five KV writes, because pageviews, human-only counters, referrers, and clicks each increment their own key. I measured this when I audited the free tier in July: the busiest day so far burned 235 writes against the 1,000-per-day free ceiling, and at five writes per visitor the ceiling works out to 200 visitors a day. My September target is 300 daily visitors, which projects to roughly 1,500 writes, or 150% of the quota. On top of the ceiling there is the correctness problem: KV has no atomic increment, so overlapping read-modify-write cycles silently drop counts, 90% of them in this morning's ten-concurrent-request probe. Today the tracker sees fewer than 100 events a day, so bursts are rare, but both problems arrive with the same traffic growth.

Three free tiers, read on the same day

These numbers come from the Workers pricing page and the Durable Objects pricing page, both fetched on August 4, 2026. One unit caveat before the table: KV meters writes to keys, while Durable Objects and D1 meter rows written. For a counter, one increment is one key write or one row write, so the columns compare fairly for this shape.

Two numbers carry the whole decision. The free write ceiling is 1,000 versus 100,000, a factor of 100, which turns my 200-visitor ceiling into a 20,000-visitor ceiling. And past the free tier, a KV write costs five times what a row write costs. The product that cannot count correctly is also the one that charges the most per count.

Why comparisons older than January 2026 mislead

This table looked different three times in the last sixteen months, which is why most of what ranks for this query is stale. Durable Objects arrived on the Workers Free plan on April 7, 2025, SQLite backend only; before that date, any comparison correctly told free-plan users that DO was not an option. Then on December 12, 2025 Cloudflare announced that SQLite storage billing for Durable Objects would switch on, and the pricing page dates the activation to January 7, 2026. The free plan is explicitly exempt from the new storage charges, so for my purposes the change clarified rather than raised the price. Since then, DO rows and D1 rows cost exactly the same, which stops being surprising once you know the architecture: Kenton Varda, who built Durable Objects, put it directly in a Hacker News comment last December: D1 is actually just a thin layer over Durable Objects. You are choosing an interface, not an engine.

What Durable Objects bill that D1 does not

Same engine, same row prices, but not the same meters. A Durable Object is addressable compute, so every increment routed to it is a billed request, and the object accrues duration charges, at a flat 128 MB memory rate, whenever it is in memory and unable to hibernate. One documented trap: an active outbound connection keeps an object in memory, and billing duration, for up to 15 minutes per connection even with no incoming requests. A counter object that only receives brief fetches should hibernate fine, so on my workload the duration meter would read near zero. My objection is simpler: the meters exist. A redirect tracker is a Worker that already runs on every click, and with D1 that Worker's UPDATE clicks SET n = n + 1 adds one row write to the bill and nothing else. The same counter as a Durable Object adds a request meter, a duration meter, and hibernation behavior to reason about. Those buy something real, serialized execution and in-memory state you could batch increments into, but at fewer than 100 events a day I have nothing to batch.

What each one does to the lost increments

The pricing argument only matters because the correctness argument already disqualified KV. Cloudflare documents KV concurrent writes as last-write-wins, which my probe confirmed this morning: ten increments in a 20 ms window, one survivor, no error. Durable Objects fix this structurally, one object instance processes requests one at a time, which is why Cloudflare's own counter example is a Durable Object. D1 fixes it at the database: the D1 docs state that D1 operates in auto-commit and that statements execute and commit sequentially, non-concurrently, with batches running as SQL transactions. A single-statement increment cannot interleave with another the way two KV read-modify-write cycles can. Ten concurrent n = n + 1 statements produce ten.

Where this lands

For this shape of workload, D1 wins on structure, and it is not close. The row prices tie with Durable Objects, the free ceiling is identical, and D1 is the only option of the three that adds no new meters to a Worker I am already running. Durable Objects earn their two extra meters when you need what they uniquely sell, in-memory coordination, WebSockets, an object per entity with state that outlives a request. A click counter needs an atomic add.

I have not migrated, and the honest reason is in the numbers above: at under 100 events a day, my exposure is bots inflating counts upward, which I measured at 35x, far more than races deflating them downward. The original KV tracker stays until the traffic argument flips, at 200-plus visitors a day the write quota and the race window both start to bite, and then the counters move to D1 in one migration instead of two. These free tiers changed three times in sixteen months, so every number above carries its read date.

FAQ

Can Durable Objects be used on the Workers Free plan?

Yes, since April 7, 2025, with the SQLite storage backend only. The free plan includes 100,000 requests, 13,000 GB-s of duration, 100,000 rows written, and 5 million rows read per day, with 5 GB of storage. The SQLite storage billing that began on January 7, 2026 applies to paid plans only; Cloudflare states free-plan developers are not charged for storage.

Is a D1 increment like UPDATE n = n + 1 atomic?

Yes. D1 operates in auto-commit and executes statements sequentially and non-concurrently, per Cloudflare's docs, and batched statements run as SQL transactions. Concurrent single-statement increments cannot overwrite each other the way concurrent Workers KV read-modify-write cycles do, so ten simultaneous increments yield ten counted.

Which is cheaper for a counter, Durable Objects or D1?

Rows read, rows written, and storage cost the same on both, because D1 runs on Durable Objects internally. The difference is the meters: a Durable Object also bills per request and for in-memory duration, while D1 called from an existing Worker adds only row operations. For a counter attached to a Worker you already run, D1 is the smaller bill and the simpler one to predict.

Pricing and free-tier numbers were read from the Cloudflare Workers and Durable Objects pricing pages and the linked changelog entries on August 4, 2026; they are quoted with that date because this table has changed three times since April 2025. The workload numbers are my own tracker's: write counts from Cloudflare's GraphQL analytics measured July 23–30, the five-writes-per-visitor figure counted from the tracker source, and the concurrent-loss probe run against the live worker on August 4, 2026. The Hacker News comment was retrieved via the Algolia HN API on the same day. Some links are affiliate links (our own product); commissions land on the public ledger.