Nation-scale Matrix deployments will fail using the community version of Synapse
Element’s move to offer “Synapse Pro” – a proprietary, Rust-based scaling layer for the open source Matrix server Synapse – has ignited debate over whether core performance and nation‑scale reliability should sit behind a paywall. Supporters argue that large governments and integrators have been free‑riding on Matrix and must fund upstream development, while critics see a bait‑and‑switch that undermines trust in Matrix as public infrastructure and pushes some toward alternatives like XMPP or Zulip. Much of the debate centers on sustainability of FOSS business models, the trade‑off between openness and paid enterprise features, and whether Matrix’s design can ever match the scalability of more traditional message‑passing protocols.
Business model and licensing
- Synapse remains AGPL-licensed FOSS; Synapse Pro adds proprietary Rust-based worker implementations aimed at very large deployments (≈100k+ users / “nation-scale”).
- Element staff say Synapse Pro exists to solve a funding crisis caused by “freerider” system integrators and governments using FOSS Synapse at scale without paying upstream, contributing to layoffs and stalled development.
- Earlier attempts to monetize via enterprise-only features and AGPL relicensing are described as insufficient; Synapse Pro is framed as a stronger incentive for big deployments to fund upstream work.
- Critics see this as open core, a bait‑and‑switch, or using FOSS as marketing, and worry about future creep of more features into the proprietary tier.
- Others argue that developers must be paid, nothing was taken away, and this is a pragmatic compromise; some suggest “eventually open source” licenses as an alternative.
Performance, scalability, and Matrix design
- Many commenters report long‑standing performance issues: high RAM/CPU use, slow joins in large federated rooms, and delayed notifications even on small instances.
- Element staff stress that small‑server slowness is due to protocol/algorithmic issues (state resolution, state storage, federation retries, full‑mesh federation), not Python vs Rust; fixes for these are promised in FOSS Synapse.
- Synapse Pro is said to only address bottlenecks for very large horizontally scaled worker setups (reduced CPU, better scaling).
- Some are skeptical that core performance can be fixed at all, arguing Matrix’s document‑replication design is inherently less scalable than message‑passing protocols.
Community reaction and trust
- Several long‑time admins and contributors feel “rug‑pulled” and less willing to advocate Matrix as public infrastructure, especially when “nation‑scale” capability is tied to proprietary code.
- Others report years of solid experience with Synapse and express strong support, viewing Synapse Pro as necessary to “keep the lights on.”
- Confusion over messaging (original blog tone, “Synapse Pro” naming, Dendrite’s status, CLAs, shifting priorities like Element X and MAS) contributes to distrust; Element later updates the post to clarify that general performance work will land in FOSS first.
Alternatives and protocol comparisons
- XMPP (notably ejabberd) is frequently cited as a more mature, scalable alternative used historically by large services; some have migrated back and are happier.
- Zulip is praised for team chat but lacks federation and broad‑audience appeal.
- A linked piece contrasts Matrix’s document‑replication model with XMPP’s message passing, arguing Matrix can’t match XMPP’s scalability by design.