The name “Durable Object” suggests that they store objects durably but the documentation, which I would like to link to :), says that state is lost if an object is evicted from memory.
The Hibernatable API addresses persistence of WebSocket connection state across evictions. The documentation states that, if an object is evicted from memory, the Durable Object’s constructor is invoked. The durability does not seem to span evictions yet, even if writes use the transactional API to persist data.
If this is correct, it seems best to preserve per-connection state that cannot be easily re-constructed in KV, D1 or some other external, resilient repository for now. I have seen projects that do this, but they don’t justify the choice. It seems a Durable Object currently resembles an in-memory store along the lines of Redis. Does this seem accurate? If so, perhaps transactional writes could optionally take a little longer to persist to durable storage. Writes are relatively uncommon for many apps and it might reduce costs for some.