I think what the OP is trying to get across is that storing text documents in which you're live-editing, will cause a lot of updates, and that these updates may be relatively big in the database (the size of the whole document) compared to the actual edit (a few characters at a time), and can also get quite large in number quickly even as a small number of people are live-editing. I don't know this for any kind of fact, but I could see how this is a fundamental architectural problem, rather than a (premature) optimization. I get that we don't need to build for infinite scale right out the gate, but I could see that the OP is possibly onto something here worth verifying at the very least.
Precisely this. There’s a difference between premature optimization and choosing the correct technology. Even then, I’m willing to compromise; for example, using a DB as a queue. Is it what they’re designed to do? Absolutely not, but it’s easy to implement, and crucially, it’s a lot easier to later shift queues – by definition, ephemeral data — than your persistence model.
