The central design question is not whether Durable Objects can store state. It is when logic should move into the stateful owner, and when the better answer is still a Worker, D1, or a more traditional service layer.
For a plain counter, D1 may be enough. The main advantage of a Durable Object is not only persistence. It is ownership and coordination.
D1 = table, rows, SQL, query model DO = identity, owner, behavior, coordination model
When all requests for one identity pass through one owner, the object can protect its own transitions and coordinate multiple clients.
D1 model: counter = row identity = row key logic = Worker DO model: counter = live identity object identity = Durable Object ID logic = inside the object
The counter is no longer merely represented by data. It has an owner.
Yes, some business logic moves into the DO. But that is not accidental leakage. It is intentional actor-model design: put logic next to the state it protects.
Not all business logic belongs in a DO.
The rule is simple: only move logic into a DO when that logic needs single-owner state, coordination, lifecycle, WebSockets, or low-latency access to its own state.
The PL/SQL idea was to keep logic close to data when consistency, concurrency, and performance matter. Durable Objects apply a similar principle, but at the level of one identity object rather than a table.
A Durable Object is better understood as object-as-a-service or actor-as-a-service. It has code, memory, identity, storage, lifecycle, and request handling.
AWS can emulate parts of this with consistent hashing, a specific ECS task or shard owner, and DynamoDB or RDS persistence. But then you are building routing, ownership, concurrency, lifecycle, and rebalancing yourself.
data-centric architecture -> row, key, SQL, stateless app identity-centric architecture -> named owner, behavior, coordination, attached storage
Durable Objects fit systems with natural identities such as room, user, tenant, document, game-room, session, or agent state.
Durable Objects are Cloudflare's primitive for putting logic next to state. They are not just storage, and they are not just compute. They are the stateful owner layer you reach for when one identity needs to coordinate itself.
Use a Durable Object when one named identity needs an owner. Keep logic outside when the problem is mostly relational, analytical, or not actually about state ownership.