Until you delete it, and that's an implementation detail as far as the actual backend storage but it's stored with the Durable Object

thats great -- but doesnt the durable object go away if there is no worker connected to it? meaning the persistent storage is gone or... will it stay there if i call the same DO with the same namespace

A Durable Object itself is an instance of a class (that you export), the Transactional Storage API saves all of the keys/values persistently to a storage backend which that given DO can access whenever it's active again (either with a request, WebSocket or alarm)

An analogy (that is a very vague one) is that think of it just like your computer.

Stuff is saved on your HDD/SSD, it's not volatile or in-memory.

You can do in-memory storage with DOs which will go away when the DO goes away

alright thats very helpful! am trying to build an amongus sort of game with DO

I'm no expert with DOs but you could think of it like you have a DO per game, use in-memory (or transactional) storage for your game state and then you can

deleteAll()

the storage when the game has ended and that DO will never cost you another penny unless you request it again.

In-memory storage is quick, inherently, but isn't resilient to failures (however infrequent they are).

greetings! i have a question regarding DO efficiency. current scenario -streaming app has chat using DO websockets. -entering a channel connects to a DO websocket. -changing channels disconnects and connects to the new websocket. (i believe this is what is causing error 1006 in our app). Support said it was due to the browser implementation. would it be better to just connect to DO websocket once and only listen for the current channel_id to populate the chat? and change channel_id when the channel changes? im just afraid if there are 100 channels open and 10 users chatting in each channel, would that blow up a users single DO websocket connection because its receiving so many messages that its ignoring.

DO doesn't have a public roadmap, but there's a feature request for both memory and storage metrics. I am curious what you would do with the knowledge that X number of DOs on the same isolate were using Y amount of memory, since you have essentially no control over that happening, short of only ever making one DO instance per script.

Is this enough to clarify that question? https://github.com/cloudflare/cloudflare-docs/pull/9090/files

We can know how much storage each DO used using grapqhl if im not wrong. I did that on my Grafana to knows how much each user is using. Anyway, for the memory footprint, my user case is two: during de dev phase: knows how much i can fit before i need to make another logic to split; For production: I have a DO that does a full text search, and each one downloads (from KV) several documents to make a index... The document size is variable, so i need to download only a small number of files to make sure that i will never blow up the memory, but is not really, really 100% sure.

" knows how much i can fit before i need to make another logic to split" i'm confused, are you saying if such an api existed, you would be calling it constantly to try to get advance notice before an OOM? again, even if that api said "DOs A and B are each using 50mb on the same isolate", what would you do? stop sending traffic to one of them?

Not exactly that.

We can slipt our model in several ways... On DO per user, one DO per group, one DO per whathaver...

Sometimes, if i put too much info on one single DO, i will use all 128M memory. Thats fine while im developing, i can test my model and knows if on the worst case scanario will works or not. Then i can just use a smaller model, split my data on more.

For runtime is diferent, on my particular case i have only one DO that can have any arbitrary number of memory use (my FTS index)... that one i do using my best hope that will never explode 😉

I really dont need that "too much"... im using DO for a long time and can live with that.

I can have the memory metrics while im developing using devtools connect to the DO... wrangler already does that.

And i can get the storage consume using graphql 😉

May i know where is the doc for pulling storage metric using grafana please ?

can you send me an example of the graphql query you're using for per-DO storage consumption? I was under the impression that durableObjectsStorageGroups is dimensioned only by date

You cant get a per object storage metric only account wide by date

yikes

I learned that here: https://github.com/skymethod/denoflare/blob/master/common/analytics/cfgql_client.ts

start here https://developers.cloudflare.com/workers/learning/using-durable-objects/#graphql-analytics

Apparently it is account wide and at most namespace filtered

Storage is the only thing missing as far as being able to see an exact cost per DO would be useful to add on for that reason. But

durableObjectsPeriodicGroups

has: - activeTime (in microseconds) - storageDeletes - storageReadUnits - storageWriteUnits - inboundWebsocketMsgCount (im assuming this is only the new api that isnt ready yet) And

durableObjectsInvocationsAdaptiveGroups

has: - requests ( Ps can we also get fetchCount, and alarmCount on durableObjectsPeriodicGroups 😛 or at the very least the request sum)

inboundWebsocketMsgCount is the old api