Matrix vs XMPP: Federated Chat Protocols Compared
XMPP is the veteran — a federated messaging protocol standardized since 1999, powering everything from early Google Talk to modern military communications. Matrix is the newcomer — launched in 2014 with the explicit goal of being “what XMPP should have been.” Both support federation, end-to-end encryption, and self-hosting. The question is whether Matrix’s modern approach justifies its heavier resource footprint, or whether XMPP’s 25 years of refinement still make it the better foundation.
Quick Verdict
For most self-hosters setting up a new chat system today, Matrix is the better choice. It has better clients (Element), easier encryption (on by default), a larger active community, and more bridges to other platforms. XMPP wins on resource efficiency and protocol maturity, but its fragmented client ecosystem is a real barrier for non-technical users.
Updated March 2026: Verified with latest Docker images and configurations.
Overview
Matrix is a decentralized communication protocol with Synapse as the reference server. It uses JSON over HTTP(S) for federation, supports end-to-end encryption via Olm/Megolm, and has a rich client ecosystem led by Element. Matrix rooms can bridge to Slack, Discord, IRC, Telegram, and many other platforms. The protocol is governed by the Matrix.org Foundation.
XMPP (Extensible Messaging and Presence Protocol, formerly Jabber) is an open messaging standard based on XML. Prosody and ejabberd are the most popular server implementations. XMPP’s extension system (XEPs) adds features like group chat, file transfer, voice/video calls, and end-to-end encryption (via OMEMO). The protocol is governed by the XMPP Standards Foundation.
Feature Comparison
| Feature | Matrix (Synapse) | XMPP (Prosody) |
|---|---|---|
| Protocol age | 2014 | 1999 |
| Data format | JSON over HTTPS | XML streams |
| Federation | Yes (built-in) | Yes (built-in) |
| E2E Encryption | Olm/Megolm (on by default for DMs) | OMEMO (XEP-0384, opt-in per client) |
| Group chat | Rooms (replicated across all servers) | MUC (XEP-0045, hosted on one server) |
| Voice/video | Element Call (WebRTC, E2EE) | Jingle (XEP-0166, client-dependent) |
| File sharing | Built-in (media repository) | HTTP Upload (XEP-0363) |
| Message history | Full room history synced to all servers | MAM (XEP-0313, server-side archive) |
| Read receipts | Yes | Yes (XEP-0333) |
| Typing indicators | Yes | Yes (XEP-0085) |
| Reactions | Yes | Yes (XEP-0444) |
| Threads | Yes (since 2022) | No standard (some clients attempt it) |
| Bridges | 20+ platforms (IRC, Slack, Discord, Telegram, Signal) | Limited (Biboumi for IRC, Spectrum2) |
| Spaces | Yes (hierarchical room grouping) | No equivalent |
| Primary client | Element (polished, cross-platform) | Fragmented (Conversations, Dino, Gajim, etc.) |
| Docker services | 2-3 (Synapse + PostgreSQL) | 1 (Prosody alone) |
| Minimum RAM | ~500 MB-1 GB | ~50-100 MB |
| License | Apache 2.0 (Synapse) | MIT (Prosody) |
Installation Complexity
XMPP (Prosody) is dramatically lighter and simpler at the infrastructure level. Matrix (Synapse) is easier to configure for modern features like encryption and bridges.
Prosody (XMPP) Docker Compose
services:
prosody:
image: prosody/prosody:0.12
restart: unless-stopped
ports:
- "5222:5222" # Client-to-server (XMPP)
- "5269:5269" # Server-to-server (federation)
- "5280:5280" # HTTP (BOSH/WebSocket)
- "5281:5281" # HTTPS
volumes:
- prosody_data:/var/lib/prosody
- prosody_config:/etc/prosody
environment:
DOMAIN: chat.example.com # Your domain
# Create admin user after startup:
# docker compose exec prosody prosodyctl adduser [email protected]
volumes:
prosody_data:
prosody_config:After starting, configure /etc/prosody/prosody.cfg.lua to enable modules like MAM (message archive), HTTP upload (file sharing), and OMEMO support. Prosody’s module system is powerful but requires manual configuration — each feature is a separate module you enable and configure.
Matrix (Synapse) Docker Compose
services:
synapse:
image: matrixdotorg/synapse:v1.149.1
restart: unless-stopped
volumes:
- synapse_data:/data
environment:
SYNAPSE_SERVER_NAME: matrix.example.com
SYNAPSE_REPORT_STATS: "no"
ports:
- "8008:8008"
depends_on:
postgres:
condition: service_healthy
healthcheck:
test: ["CMD-SHELL", "curl -fSs http://localhost:8008/health || exit 1"]
interval: 15s
timeout: 5s
retries: 3
start_period: 30s
postgres:
image: postgres:16-alpine
restart: unless-stopped
volumes:
- postgres_data:/var/lib/postgresql/data
environment:
POSTGRES_DB: synapse
POSTGRES_USER: synapse
POSTGRES_PASSWORD: CHANGE_THIS_PASSWORD
POSTGRES_INITDB_ARGS: "--encoding=UTF-8 --lc-collate=C --lc-ctype=C"
healthcheck:
test: ["CMD-SHELL", "pg_isready -U synapse -d synapse"]
interval: 10s
timeout: 5s
retries: 5
volumes:
synapse_data:
postgres_data:Generate config before first run: docker compose run --rm synapse generate. Encryption works out of the box. Federation works once you add DNS SRV records or .well-known delegation. Bridges are separate containers but well-documented.
Performance and Resource Usage
| Resource | Matrix (Synapse) | XMPP (Prosody) |
|---|---|---|
| RAM (idle, small server) | ~300-500 MB | ~30-80 MB |
| RAM (100 users) | ~1-2 GB | ~100-200 MB |
| RAM (1,000 users) | ~4-8 GB | ~500 MB-1 GB |
| CPU efficiency | Poor (Python, single-threaded) | Excellent (Lua, event-driven) |
| Federation overhead | High (full room state synced) | Low (messages forwarded, not replicated) |
| Database growth | Fast (rooms replicate across servers) | Moderate (local archives only) |
| Docker services | 2-3 | 1 |
XMPP is an order of magnitude lighter than Matrix. Prosody can serve hundreds of users on a Raspberry Pi. Synapse struggles with large federated rooms even on dedicated hardware. This is Matrix’s most significant weakness — the protocol design requires every server in a room to hold a full copy of the room state, which scales poorly.
The Conduit (Rust) and Dendrite (Go) alternative Matrix servers reduce resource usage, but they lag behind Synapse in feature completeness.
Community and Support
| Aspect | Matrix | XMPP |
|---|---|---|
| Protocol governance | Matrix.org Foundation | XMPP Standards Foundation |
| Server implementations | Synapse (Python), Conduit (Rust), Dendrite (Go) | Prosody (Lua), ejabberd (Erlang), OpenFire (Java), 10+ others |
| Synapse GitHub stars | ~42,000+ | ~3,800+ (Prosody) |
| Client quality | Element is polished, consistent UX | Fragmented — each client supports different XEPs |
| Bridge ecosystem | Extensive (mautrix bridges) | Limited |
| Documentation | Comprehensive (matrix.org/docs) | Scattered across XEP specs and server docs |
| Active community | Growing rapidly | Stable, established |
Matrix’s community is growing faster, but XMPP has a deeper pool of institutional knowledge. XMPP is used by militaries, medical systems, and IoT deployments where long-term stability matters more than growth.
The Client Problem
This is XMPP’s biggest weakness and Matrix’s biggest strength.
Matrix: Element is available on iOS, Android, desktop, and web. The user experience is consistent across platforms. It handles encryption, verification, file sharing, and voice/video calls. One client, one experience. Third-party clients (FluffyChat, SchildiChat, Nheko) exist and work well too.
XMPP: No single dominant client. Conversations (Android), Dino (Linux), Gajim (Windows/Linux), Monal (macOS/iOS), Siskin (iOS) — each supports a different subset of XEPs. Conversations might support OMEMO but not Jingle video. Gajim might support file transfer but not voice calls. Users on different clients have different feature sets, which creates a frustrating experience.
Use Cases
Choose Matrix If…
- You want polished clients that non-technical users can adopt
- End-to-end encryption by default matters
- You need bridges to Slack, Discord, IRC, or Telegram
- You’re building a community (Spaces replace Discord servers)
- Consistent cross-platform experience is important
- You have sufficient server resources (1+ GB RAM)
Choose XMPP If…
- Resource efficiency is critical (running on Raspberry Pi or low-spec hardware)
- You need a proven protocol with 25+ years of stability
- IoT, embedded, or machine-to-machine messaging is your use case
- You prefer protocol-level standards over application-level features
- Your users are technically sophisticated and can handle client configuration
- You want maximum server implementation choice (Prosody, ejabberd, OpenFire, etc.)
Final Verdict
For a new self-hosted chat deployment in 2026, Matrix is the more practical choice. Element provides a user experience that non-technical people can actually use. Encryption works out of the box. Bridges let you connect to nearly any other platform. The resource cost is real but manageable on any VPS.
XMPP remains the right choice for environments where resource efficiency, protocol maturity, or IoT integration matter more than client polish. Its 25 years of battle-testing and institutional adoption speak to reliability that Matrix hasn’t yet proven at that scale.
FAQ
Can Matrix and XMPP federate with each other?
Not natively. They’re separate protocols. You can bridge them using Bifrost (a Matrix-XMPP bridge), but it’s experimental and not recommended for production use. In practice, you choose one protocol.
Is ejabberd better than Prosody?
ejabberd (Erlang) handles more concurrent connections and has built-in clustering for high availability. Prosody (Lua) is simpler to configure and uses less resources. For small to medium deployments (under 1,000 users), Prosody is easier. For large deployments, ejabberd scales better.
Will XMPP die?
XMPP has been “dying” according to the internet since 2013, yet it’s still used by the French government (Tchap), the German military (BwMessenger), and major IoT platforms. The protocol is stable and entrenched. It won’t grow like Matrix, but it’s not going anywhere.
Related
Get self-hosting tips in your inbox
Get the Docker Compose configs, hardware picks, and setup shortcuts we don't put in articles. Weekly. No spam.
Comments