Cloudflare is not trying to solve the state problem with one abstraction. Its approach is to slice the problem into separate mechanisms: fast reads, consistency repair, coordination, code locality, data locality, and compliance boundaries.
D1 begins with a simple promise: a SQLite-like database for Workers. The moment you add global users, that simplicity changes.
Worker -> nearest or eligible read replica Worker -> primary for writes
Read replicas improve latency, but they introduce lag, stale reads, and session-level consistency questions.
Sessions API and bookmarks are the platform's way of saying "this user must see data at least this fresh."
Which replica? Which session? Which bookmark? Which consistency level?
It is a sensible repair mechanism, but it also means the developer has to think explicitly about freshness.
Durable Objects solve a different slice of the same problem: coordination through a single globally unique owner.
Workers = stateless global compute D1 = relational data DO = single-owner state and coordination
That is useful for sessions, locks, chat rooms, per-tenant coordination, and small transactional workflows.
Running near the user is not always right. A Worker that talks constantly to a database in another region may need backend-local execution instead.
default placement smart placement region-based placement host or hostname-based placement
Then sovereignty adds another layer: jurisdictions, location hints, Regional Services, and metadata boundaries.
| Problem Slice | Cloudflare Answer |
|---|---|
| Stateless edge compute | Workers |
| Code locality | Workers placement |
| Relational state | D1 |
| Fast global reads | D1 read replicas |
| Read-after-write consistency | Sessions API and bookmarks |
| Coordination or single-owner state | Durable Objects |
| Object storage | R2 |
| Eventually consistent config or global data | KV |
| Async processing | Queues and Workflows |
| Data residency | D1 jurisdictions and Data Localization |
| Request-processing locality | Regional Services |
| Hybrid AWS, GCP, or Azure reality | Region and host placement |
The problem is not one problem. Cloudflare is decomposing state into many narrower classes of difficulty.
Each primitive addresses a real constraint that appears when applications become global, stateful, or regulated.
Each mechanism makes sense in isolation. The complexity comes from having to combine them coherently in one application design.
Cloudflare's approach is to split the state problem into slices and assign a platform primitive to each slice. That is powerful, but it guarantees a larger conceptual surface area.