A number of platforms like Google Docs and Notion supports real-time collaboration. But MediaWiki's revision storage stores all revisions in single flat table and keep them permanently with no meaningful way for pruning. So storing a new revision when someone added something is not a scalable approach (T415237: etherpad table size is 233GB / plan to delete all etherpads in April 2026 mentions current Wikimedia Etherpad has 490 million entries, which is twice the number of revisions of French Wikipedia). If someone implemented a CollabPad, we should make sure not to store every single modification - which can be addition of one single word or even letter - forever; though we can provide such a fine-grained history for a limited time. This may need to design a new type of revision storage schema, since currently MediaWiki does not allow one revision having multiple authors, and backend storage system (current ExternalStorage is append-only and can not be purged).

N.B. the traditional (non-LQT and non-Flow) discussion system stored many text redundantly since usually only a small part of big discussion page is changed (T321716 will obviate but not completely resolve it), but it is mostly an issue of ExternalStorage, not revision table (i.e. number of revisions). However, saving a new revision when someone added a new word will bring much more revisions and is likely unacceptable.