Hi. I’m kinda of a noob in the world of self-hosting and matrix, for that matter. But I was wondering how heavy is it to host a matrix server?
My understanding how matrix works is each participating server in the room stores the full history and then later some sort of merging happens or something like that.
How is that sustainable? Say in 5 years matrix becomes mainstream and 5 people join my server and each also join 3 different 10k+ people rooms with long histories. So now what I have to account for that or people have to be careful of joining larger rooms when they sign up in a smaller-ish server?
Or do I not understand how Matrix works? Thanks.
You must log in or register to comment.
There are different server implementations. I run tuwunel and haven’t had problems. It seems about as performant on my VPS (8GB RAM, 4 CPUs at 2.4 GHz, hosting other services not just tuwunel) as matrix.org was when I used that.
Matrix runs great out of the box but once you start joining large rooms your server has to synchronize with every instance, this is very taxing on the network and in my experience was essentially DDOS’ing me until I started a cache at the reverse proxy level and forced it to use my secondary PiHole.
I’m hosting a matrix instance using synapse on a shitty old laptop with 8 gigs of RAM and a Ryzen 3 2200U
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
Fewer Letters More Letters DNS Domain Name Service/System PiHole Network-wide ad-blocker (DNS sinkhole) VPS Virtual Private Server (opposed to shared hosting) XMPP Extensible Messaging and Presence Protocol (‘Jabber’) for open instant messaging
3 acronyms in this thread; the most compressed thread commented on today has 9 acronyms.
[Thread #126 for this comm, first seen 2nd Mar 2026, 07:50] [FAQ] [Full list] [Contact] [Source code]
Not good on raspberry pi4. It worked but slow…
TLDR: bare Synapse was fine on 1CPU 1GB RAM VPS, but uses lots of disk space (from large rooms). Current/future ESS requires Kubernetes and several services to be functional.
Nothing requires kubetnetes. Can you scale with kubetnetes easier? Maybe, but then you’d have to learn kubetnetes. Even super scalers like Netflix ran for decades without kubetnetes and then for other reasons they moved. Self hosters only need kubetnetes if they want to learn it.
It’s possible to run the services without Kubernetes, but official ESS Community uses Kubernetes.
ESS Community works ‘out-of-the-box’ on a single machine or existing Kubernetes cluster using the provided Helm charts.
I don’t know, I would not recommend kubernetes to most people not already familiar with it, but especially to beginners. It’s too many moving parts, and fir most selfhosted setups, its capabilities are not needed I think.
I wanna reshare my experiences here. Essentially it doesn’t scale well with large rooms, and isn’t friendly with janky/underpowered equipment like XMPP. But with a lot of performance tuning it can go a long way.
For a room, the amount of servers you federate with is a more reliable metric than member count (so 5000 accounts on 2 servers would likely take less load than 500 accounts on 500 servers, as an example). There are some large public rooms that are very broken, and I advise banning them before users get to join
and I advise banning them before users get to join
Why does this feel like a fundamental problem to me?
I don’t know about other homeserver implementations but synapse kinda sucks. It used to randomly eat 100% of 1 or 2 CPU cores (including the database) until I tracked it down to 3 rooms having a messed up state which caused costly SQL queries. I removed the rooms from my server (using a third party admin panel because there’s no proper admin GUI built in, the documentation just mentions curl commands to hit the admin API, with placeholders to manually replace). It has been fine since I did it, but I’m the only user on my server. And I expect other issues to come up at any time…
It also eats a lot of storage, mostly the database. It grew very large quickly, but it’s more stable now
This is a fundamental issue of the Matrix protocol, yes. For regular small scale use it doesn’t matter so much, and the state history gets reset every time you do a room upgrade, which is another annoying “feature” of Matrix, but it eases the fundamental problem a bit.
But IMHO the Matrix protocol is a child of the Bitcoin hype era and is built on a similar data-structure that is inherently impossible to scale and the developers of Matrix should have realized that early on. Their bosses back then actually did, but they spun it off as a separate company and got some crypto-currency investments so the can was kicked down the road and here we are…
Is there a good alternative that you would recommend?
XMPP obviously. Have a look at https://joinjabber.org/
Still staggering to me that XMPP isn’t the default, since it was used in many chat apps in the late 90’s.
What client(s) do you use/prefer?
Like many, I am looking for a Discord replacement and (possibly hot take) I largely like Discord’s layout, UI, and chat flow. That is to say, I like threads, channels, categories, and “servers” (spaces, what-have-you) to partition my chat experience. There are a few Matrix clients that replicate this closely, but the XMPP ones I have seen so far at least were not very enjoyable user experiences for me.
(Not for nothing, I also have been able to get a Synapse server running on my homelab, but have thus far not been able to successfully get an XMPP server running so that’s not helping my experience either)
Happy to check out your suggestions.
it seems like movim is the most discord-ish xmpp client
Does it do screen sharing, group calls, etc.?
Screensharing is the only thing i dont think it does. Voice and video good. See snikket or conversations.im
Neither of those client promo pages mention group calling. le sigh
I believe group calling is only a thing certain clients (e.g. Dino, Movim) support, although there is a initiative to implement it on protocol level as far as I am aware.
So, Onomatopoeia there is wondering why xmpp isn’t standard, and I’m getting the sense that it is targeted at oldskool usage.
Discord is popular because it’s easy to start using, it has collaboration features like group screensharing, and it doesn’t assume an ubernerd is the target audience.
Maybe we’ll get a more unified, feature rich xmpp implementation, but until then, sounds like matrix/element is closer, despite its warts.
Yeah you could consider it old school, or maybe just a product of another time were people didn’t mind to use multiple software for different uses.
I for one don’t mind using Mumble for voice and XMPP for text chat or one to one calls for example.
I don’t have a computer or smartphone so I only can install one app and that’s it. And I know I might be in the minority when it comes to that, at least compared to the general public. For gods sake it’s already hard to get people to install a second messenger app, not even trying to get them off WhatsApp or other meta crap…
Any source for the coin stuff? Never read about it
You could even argue it with the data structures and the protocol itself: Modelling chat rooms as graphs (“directed acyclic graphs”), which need to be eventually consistent from beginning to end is plain madness for big and long-living public spaces. This blog post is a good collection of some of the major problems coming from that: Why not Matrix? - telegra.ph
I knew of some of these issues with the protocol, but this article definitely gives an impression that Matrix was built as a “cool protocol” first, with messaging applied on top as an afterthought.
Welp. This comment has completely killed all my enthusiasm for matrix 😅 I had no idea it was such a horrible mess under the hood…
I’m trying to move some communities off Discord to something self hosted but I don’t know enough about SMPP to know if it would do the job.
They (Element / New Vector) got a major early investment in 2018 from Status, a cryptocurrency/web3 company, and later in 2021 an even bigger one in relation to Protocol Labs, who peddle their own cryptocurrency.
It can baloon as it scales up. Matrix.org (homeserver) has had at least one DB corruption and that’s with their proprietary Rust bindings for Synapse. Small communities, especially ones that share rooms between them, should be fine on most systems. Make regular backups of the DB.
Make regular backups of the DB.
tbh that should apply to any kind of selfhosted service, especially when its not only for you
And, importantly, run the db on postgre, not sqlite, and implement the regular db maintenance steps explained in the wiki. I’ve been running mine like that in a small VM for about 6 months, i join large communities, run whatsapp, gmessages and discord bridges, and my DB is 400MB.
Before when I was still testing and didn’t implement the regular db maintenance it balloned up to 10GB in 4 months.
It is my understanding that all of the ballooning DB is room states, something that you can’t really prune. What exactly are you pruning from the DB?
I purge 2 weeks old media using these. Then I purge the largest rooms’ history events using these. Then I compress the DB using this.
It looks like this:
export PGPASSWORD=$DB_PASS export MYTOKEN="mytokengoeshere" export TIMESTAMP=$(date --date='2 weeks ago' '+%s%N' | cut -b1-13) echo "DB size:" psql --host core -U synapse_user -d synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));" echo "Purging remote media" curl \ -X POST \ --header "Authorization: Bearer $MYTOKEN" \ "http://localhost:8008/_synapse/admin/v1/purge_media_cache?before_ts=%24%7BTIMESTAMP%7D" echo '' echo 'Purging local media' curl \ -X POST \ --header "Authorization: Bearer $MYTOKEN" \ "http://localhost:8008/_synapse/admin/v1/media/delete?before_ts=%24%7BTIMESTAMP%7D" echo '' echo 'Purging room Arch Linux' export ROOM='!usBJpHiVDuopesfvJo:archlinux.org' curl \ -X POST \ --header "Authorization: Bearer $MYTOKEN" \ --data-raw '{"purge_up_to_ts":'${TIMESTAMP}'}' \ "http://localhost:8008/_synapse/admin/v1/purge_history/$%7BROOM%7D" echo '' echo 'Purging room Arch Offtopic' export ROOM='!zGNeatjQRNTWLiTpMb:archlinux.org' curl \ -X POST \ --header "Authorization: Bearer $MYTOKEN" \ --data-raw '{"purge_up_to_ts":'${TIMESTAMP}'}' \ "http://localhost:8008/_synapse/admin/v1/purge_history/$%7BROOM%7D" echo '' echo 'Compressing db' /home/northernlights/scripts/synapse_auto_compressor -p postgresql://$DB_USER:$DB_PASS@$DB_HOST/$DB_NAME -c 500 -n 100 echo "DB size:" psql --host core -U synapse_user -d synapse -c "SELECT pg_size_pretty(pg_database_size('synapse'));" unset PGPASSWORDAnd periodically I run vacuum;
Thank you for the queries. The rhetorical question is why isn’t the server handling this.
I don’t know, can’t speak for the devs. It is weird that if you don’t implement these API calls buried a bit deep in the wiki, you end up storing every meme and screenshot anybody posted on any instance for the rest of time. But I found these through issue reports with many people asking for these to be implemented by default with for instance a simple setting “purge after X days” and a list of rooms to include or exclude from the history clean-up.
are the media files redownloaded from other servers when someone tries to load them? I guess all local media is lost forever, but maybe not remote ones
There’s also issues with the state disagreement / resolution algorithms across federation.
Has this been solved? Maybe it’s also due to database corruption, where some state is forgotten across the federation, and thus the algorithm breaks down?
Barely 1-2% CPU usage. Using synapse.
yeah me too it’s mostly very chill
