Well, this is kind of like asking the throughput of an individual Worker instance. It doesn't really matter, because the system automatically spins up as many as you need, and so the overall throughput is effectively unlimited.

For Durable Objects, applications should aim to make their objects as fine-grained as they reasonably can, so that the limits on one object are not likely to matter. Meanwhile, the total capacity across all objects is effectively unlimited.

Anyway, we don't have numbers for these questions yet. This is an early beta and we still have a lot of low-hanging fruit optimization to do.

But isn't each (say) chat room a single object, and each is single-threaded (per answer elsewhere on this page).

It's nice to know that if "N" chat rooms get started, "N" instances are built, but if 100k people join one chat room, it's going to bog at best, and flame out at worst. Or am I guessing wrong?

Consider that a human can probably only keep up with, at most, a couple chat messages per second (and that's generous). But a Durable Object can handle orders of magnitude more than that. So the scalability bottleneck for the chat use case is actually humans, not the limits of a Durable Object.

Many use cases end up being this way.

With that said, if you really wanted to support a chat room that has more traffic than a single object can handle, the way to do it would be to shard the object. E.g. have 10 chat room "shards", have each client connect to all 10, and randomly choose a shard to handle each message sent. Or if it's the number of clients (not the frequency of messages) that is a limiting factor, have each client connect to only one shard, but have the shards rebroadcast to each other. (This is two possible designs, but there are many other options depending on what you're trying to accomplish.)

If you're getting near the limit of what one Durable Object can handle, you probably should introduce such sharding into your app. Once you have sharding, you can scale easily again, by adding shards.

We'll likely add tools so that the system can handle various sharding approaches automatically for you.

In practice splitting things into fine-grained objects with async messaging is hard. Well, it depends...

How fine-grained?? Which is essentially the question I'm asking.

Would I need a hierarchy of durable objects to store a 100kb collaborative text document? What about 10MB?

You can make things very fine-grained, if you want to.. but at some point you're essentially implementing distributed consensus algorithms -- and then it might be better to just use a single point of failure like a database..

> Would I need a hierarchy of durable objects to store a 100kb collaborative text document? What about 10MB?

The bottleneck is going to be more CPU than memory or storage size. So the question is, how many users are editing, what rate of events does each generate, and how complex is the event handler?

Let's say it's actually a plaintext editor, with the 10MB text file represented in memory using a reasonable data structure allowing O(1) insertions and deletions. Clients send a stream of keystrokes to the server. Server writes document out to disk periodically, not on every keystroke. Then I would expect each keystroke to take less than 1ms of CPU time to process, therefore at least 1000 per second could be processed by one thread. Let's say people type 10 keystrokes per second, then you could have 100 users actively typing at once? This is just my intuition, though.

> and then it might be better to just use a single point of failure like a database..

Incidentally databases will also hit scaling bottlenecks if you have too many requests hitting the same row. Under the hood, the database has to do exactly what Durable Objects do -- the row will be owned by one "chunk" which has to serialize all changes (making it effectively single-threaded).

So "use a database" doesn't necessarily solve your scaling bottleneck. In fact, it's likely to be worse, since the database chunk is not running app-specific optimized code.

> So "use a database" doesn't necessarily solve your scaling bottleneck.

Absolutely, it won't :D

I'm just saying that if I do a postgres database on say heroku, I have a clue what it can handle. I get the specs, it has this much RAM, this many CPUs and this much storage.

I also know that I'll be the only user of said server.

With other hosted services like S3, dynamodb, azure tables, etc, the documentation features "scalability targets".

S3 I can see how may reads / s a bucket can handle, and how it scales up. On azure tables I know a table can handle 100k writes / s (or so).

If I send a lot of messages to a single durable object, will it scale to the point where it gets a dedicated node? (what is the approximate definition of node) Will it migrate automatically? (what temporary degration might I see).

Can I have a 1GB durable object with 1 transaction every 1 hour? What about a 100 GB durable object with a 1 transaction every day?

Can I have a 1MB durable object with 10 messages per minute?

Or is it measured in compute seconds, clock cycles?

Liek can I have 10kb durable object with 10 messages / s each using 0.5ms CPU time?

Similarly, how does it look when I increase CPU time per message, number of messages or size of the object, where are the limits?

From reading the documentation one might think one could store a 100GB git repository as a durable object. Sure each commit takes time, but I have few commits / hour.

(I assume a 100GB durable object won't work, but I can see any limits or scalability targets in the documentation)

Just to clarify, I don't expect an answer to the question above, I expect documentation to feature some "scalability targets" and "limits". Something that gives me an intuition about what a durable object can handle. - So I know whether to shard my use-case or not :D

On topic: I think durable objects is really cool, message passing seems like the right model for scalable cloud computing.