This isn't a hard limit, but more an estimated of what the system can handle

May be more or less depending on the amount of computation you do on each request.

If you can make the traffic spread out across a numer of DO instances (for instance: one per user and/or one per channel) it could work nicely. I think one per tweet would be too fine grained though. The part you have to figure out though is in connecting the traffic to the correct instance. If everything goes through one DO instance as a sort of router it can be easily overwhelmed. So, either have some external "name" and use

idFromName()

or use some other mechanism as a lookup. I don't believe D1 is a good choice if you need to get to production within the next 6 months. Too early. KV though is potentially a good option if you can live with eventual consistency which is generally true with twitter-like use cases.

BTW, DO storage costs are lower than KV storage costs so I don't think DOs would result in more expense. Possibly less.

thanks

can't access the service binding from DO is this a bug or a feature?

the worker that calls DO has access to service binding, but once inside the DO, this binding disappears. How can this be solved? Local environment

I believe DOs have the bindings/environment of their defining worker

1 console is in fetch woker, 2 console is inside DO in the constructor

Am I the only one with this problem? local development

Service bindings for Workers/DOs are defined in

wrangler.toml

Would be nice to bind durable objects on namespace id instead of script name, i am not sure why this was done on name instead of namespace id like KV.

Might be because DOs are user-defined, while KV namespaces are not

did you answer me? I did this. The screenshot in the worker has this bindings, but inside the DO it is not accessible

any examples, good docs how to migrate / transfer objects ?

with data

I haven’t had to do this in anger yet, but what are you trying to do exactly, because that matters a lot in how I would approach it. Are you like renaming keys, sharding one DO into multiple ones, doing something else? Do you have lots of writes going on, or is the data relatively stable after it is written? Etc.

I'd like to understand pricing of DOs better, so hopefully someone here can help 🙂 our use case would involve a lot of instances, but the examples here are 100 max: https://developers.cloudflare.com/workers/platform/pricing/#durable-objects - one DO with one instance per user - 100,000 users per day, i.e. 100,000 DO instances - each DO instance would be active (exist) for 15 minutes (900s) on average per user ==> 90,000,000 seconds * 128 MB / 1 GB = 11,520,000 GB-s = $144 ? 😱 - each DO instance would be called 25 times on average ==> 2,500,000 requests = $0.375 ? I am ignoring the free tier, but is this calculation otherwise correct? i am worried about the active time because it would make this not worthwhile. however, i may define active time incorrectly, because the example from the linked docs mentions "a single Durable Object that was called by a Worker 1.5 million times, and was active for 1 million seconds", which suggest to me that "being active" is not the time a DO instance exists (but the docs also mention that 128 MB are billed for each DO instance, so maybe my initial calculation is correct). if a DO instance is only active while it is being read or written to, the time would probably be 15s instead of 900s, which would bring the costs down from $144 to $2.4. based on your experience, is "active time" in seconds usually close to the number of requests? follow-up question: in the announcement blog post (https://blog.cloudflare.com/durable-objects-open-beta/), the pricing model at the bottom distinguished between read, write, and delete operations. this has since been removed and replaced with the 128 MB billing, right? the initial pricing model would have worked for us, but if so much RAM is billed, we can't use DO 😦

You are charged per request, duration, and storage ops. Assuming you did the conversion to GB-seconds correctly the $144 for duration does look correct. And active time is how long a specific object is handling requests. So the faster your requests the lower the active time is, the longer each request takes the more active time you have.

And if you have many requests in parallel to the same object ID the duration for that object doesn't grow exponentially the object has its own timer separate from each request that counts for billing

Thank you very much for your quick response, @Unsmart | Tech debt! 🙂 does "active time" include idle time? DO instances would exist for 15 minutes on average, but there would only be 25 requests on average during that time, which would be very quick, 1-2 seconds max. to your last point: there should usually not be parallel requests because they (25 per ID) are distributed over roughly 15 minutes

No active time is only while it's handling a request

oh wow, that's awesome! in that case DO looks like a possible solution 🙂

Keep in mind that, at the moment, having a websocket open to the DO does keep it active. Normal requests, however, only count from the time the request comes in until the time the response goes out

but i hope that there is no misunderstanding, because the docs explicitly mention that all instances are billed for their 128 MB. but if they are only billed, when instances handle requests and not when they are idle, this would be fine for us 🙂

They are billed 128MB. Just only when you are actually using it

> Duration is billed in wall-clock time as long as the Object is active, but is shared across all requests active on an Object at once. Once your Object finishes responding to all requests, it will stop incurring duration charges.

thank you for this tip, we would connect from individual Worker invocations, meaning it would be a quick read/write and then a disconnect