Matrix project lead here; we've been making steady progress on performance issues, and since we exited beta a few weeks ago (https://matrix.org/blog/2019/06/11/

Matrix project lead here; we've been making steady progress on performance issues, and since we exited beta a few weeks ago (https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-and-the-matrix-org-foundation/ https://matrix.org/blog/2019/06/11/introducing-matrix-1-0-an...) we now have much more bandwidth to improve it. We were consciously following a "make it work, make it work right, make it work fast" philosophy. For instance, as of a few days ago we have a tentative fix for one of the biggest causes of high RAM usage in Synapse (the reference server implementation): https://github.com/matrix-org/synapse/pull/5480 https://github.com/matrix-org/synapse/pull/5480. If this tests out okay in the wild it should land in the next release. Meanwhile, my personal server idles at around 600MB of RAM (across a few hundred conversations, some in quite large rooms), although there's room for us to reduce that by at least a factor of 10. It's important to understand that Matrix is effectively a system for replicating chat history - it's more like USENET or Git than (say) XMPP or IRC. As a result, the resource utilisation depends entirely on the complexity/size of the rooms you participate in. A single person server where that user joins thousands of public chatrooms with hundreds of thousands of users is going to use a lot more RAM than a 10,000 person server where everyone is in small private chats. Finally, a lot of Matrix's reputation for bad performance comes from the fact that the default sqlite database is not remotely optimised at all, and performs horrifically badly as soon as you start federating with the rest of Matrix. You have to use Postgres these days. Also, if you do end up with a heavily used server, you have to manually increase the cache sizing in the config; it doesn't autotune the caches yet. So to conclude: * Run Python3 * Run PostgreSQL * If your users are joining lots of large rooms, you'll need to manually increase the cache factor to avoid hammering the DB. Alternatively, you can now cap the size of rooms your server is allowed to participate in (https://github.com/matrix-org/synapse/issues/5069 https://github.com/matrix-org/synapse/issues/5069) ...and you should be relatively fine.