The collaborative editor module uses three differenta tables: ce_node, ce_pchanges, and ce_users
As I consider myself a non expert in db performance and scalability I some points of the application so the rest of developers can improve the performance for future versions of the module
Besides different common techniques like catching, it will also be necessary to reduce how many times the data is read from the database and, if needed, to find alternatives like store the data in memory, xml, etc
It's necessary to see the workflow for each use case and avoid to pass parameters that are not used later either in client or in server side. In some cases, if a user hasn't uploaded new content it should be unnecessary to read the revision id from the database, unless there are changes from others. For now, there is an access to the database on every asynchronous call. So it has to be optimized the frequency of the asynchronous calls depending on the user actions (see HeartBeat pattern).
The pending changes are stored in one field serializing and deserializing the data. And the active users are updated in a relational table every time they enter or leave the document. Of course, these kind of actions need to be reviewed to see if they are using the best procedure
Some useful tools to check the performance:
HTTP Load
ValGrind
Kcachegrind
...