I think it sounds like premature optimisation too. To ever hit these problems would mean the project had been a roaring success. And they would be much easier to fix later than complicating installs early on.

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.

At scale, I can definitively say that yes, Postgres becomes the bottleneck for this. The company I worked for was using the same libraries, the same stack.

Re: optimize it later, your persistence model is the hardest thing to change once it’s built and full of data. I strongly recommend getting that right the first time.