I have set up this demo maf.chat homeserver on my own systems using the matrix-synpase package on the Fedora 36 linux distribution. The demo can be easily migrated to your own installation of the same (Synapse) implementation.
Synapse uses a good deal of RAM. Our family homeserver with dozens of active users has 4G. The critical factor is actually the number of homeservers participating in a room. So joining a large public room on the matrix.org homeserver can be resource intensive.
All room are cryptographically signed append only logs. The Matrix protocol defines how events are ordered when homeservers synchronize events in a shared room. With Synapse, there are two growing uses of disk space. The media directory stores media files like photos and videos posted to rooms. They are stored by sha256 hash, and if local media is lost, can be recovered from another homeserver sharing the room. This currently takes up 1.6G for local media and 6.5G for remote media. This obviously grows.
Synapse uses a Postgresql database for users, rooms, events, messages, and so on. It can also use sqlite for testing - but don’t even think about using it in production. The database for our family server is currently 23G, representing nearly 2 years of operation. This obviously grows.
Most homeservers support a retention policy. Old messages are slowly removed in the background - while making sure to keep the required length of history. In theory, this should keep storage within stable limits. But in my 40 year career, no customers have ever used the rather complex retention code for our business accounting and operation systems. Disk drives wear out, and new ones generally hold twice as much. This may change with the Great Reset threatened by some world leaders.
Regardless of homeserver retention policy, users can simply create a new room, post a “tombstone” message to the old room with a link to the new room, and make the old room read-only.
When all users leave a room, the empty room is held for a while, then deleted entirely. An empty room can be rejoined before it is actually deleted.
I recommend using tombstones and new rooms with the same name to archive old history. This creates more documentation than a retention policy, and the historical rooms can be kept read-only as long as they are useful. A special role such as “librarian” should join archival rooms to prevent their deletion before MAF policy dictates.