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.
Comments
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.