Matrix Synapse vs Dendrite vs Conduit: Lightweight Server Comparison

Choosing a Matrix homeserver is less about finding the server with the smallest binary and more about choosing the operational trade-offs you can live with. Synapse, Dendrite, and Conduit all speak Matrix, but they differ in maturity, implementation language, database model, scaling path, and how much compatibility risk an administrator should accept. As of October 5, 2026, the official Matrix server directory lists Synapse as Stable and both Dendrite and Conduit as Beta. That maturity difference should carry more weight than vague claims that one option is “lightweight.”

This practical comparison focuses on what is documented and verifiable today. It does not claim universal RAM or CPU winners because the projects do not publish a single controlled benchmark that fairly represents all three under the same users, rooms, federation traffic, media load, database tuning, and hardware.

Quick comparison: which server fits which job?

Source check: see the official Matrix homeserver directory, the Synapse installation documentation, the Dendrite Docker installation documentation, and the Conduit generic deployment documentation.

What “lightweight” actually means for a Matrix homeserver

“Lightweight” can refer to at least four different things: idle memory use, CPU consumption during sync and federation, storage growth, or the number of supporting services an administrator must run. Those measurements can point to different winners. A single-user homeserver that joins a few private rooms behaves very differently from a server that joins huge public rooms, bridges multiple networks, stores years of media, or participates heavily in federation.

For that reason, treat resource claims as workload-dependent unless they are backed by a reproducible benchmark that matches your deployment. The most useful action is to define your expected workload first: number of local users, largest rooms you intend to join, whether federation is enabled, whether you need bridges or appservices, expected media volume, and whether you need high availability.

Synapse: the safest compatibility-first choice

Synapse remains the conservative choice when you want the broadest operational track record. Matrix.org describes it as Stable, while Element actively maintains the current repository. At the time of this review, the latest stable GitHub release is Synapse 1.162.0, released September 29, 2026. You can verify current releases in the official Synapse release page.

Synapse is often described as “heavy,” but that needs context. The project deliberately keeps caches in memory to improve request performance. Its admin FAQ explicitly notes that the architecture can be RAM-hungry. The installation guide also says to have at least 1 GB of free RAM if you want to join large public rooms. That is a useful floor for planning, not a guaranteed requirement for every small private deployment.

Database and scaling model

Synapse can start with SQLite, but the official installation documentation says almost all installations should use PostgreSQL and that SQLite should not be used for a production server. This matters because the “easy single-file database” advantage largely disappears once you deploy Synapse properly for long-term use.

Synapse also has the clearest documented scale-out route of the three. Small installations can run as a monolith; larger installations can split work across multiple processes called workers. The current Synapse worker documentation explains that worker deployments share PostgreSQL and can divide client and federation workloads among processes. This adds operational complexity, but it gives you an explicit path when one process is no longer enough.

Choose Synapse when

• You need the most mature option in this comparison.
• You expect to use bridges, appservices, administration tooling, or less-common Matrix features and want to minimize compatibility surprises.
• You are willing to operate PostgreSQL for production.
• You may eventually need worker-based scaling.

Action: if resource use is your only reason for rejecting Synapse, test it with PostgreSQL on your actual workload before assuming it is too large. Idle memory alone is not a good proxy for federation performance or large-room behavior.

Dendrite: a Go-based alternative that is still Beta

Dendrite was created as a second-generation Matrix homeserver in Go. The old matrix-org repository was archived in November 2024, but that does not mean Dendrite disappeared. Development moved to the Element Dendrite repository, which remains active. The official Matrix server directory still labels Dendrite Beta.

This distinction matters because older articles can leave readers with two opposite misconceptions: either that Dendrite is abandoned, or that it has already replaced Synapse. Neither is accurate as of October 2026. It is maintained, but its official maturity remains Beta.

Deployment and database considerations

The documented Docker Compose path for Dendrite uses PostgreSQL as its dependency and runs the homeserver in a monolith configuration. That makes the basic production-style architecture easy to understand: reverse proxy, Dendrite, PostgreSQL, and the usual Matrix DNS/TLS setup.

Dendrite’s Go implementation is appealing to administrators who prefer a compiled binary and Go’s operational ecosystem. However, language choice alone does not prove lower real-world resource consumption. Federation state resolution, room size, media, database behavior, and client sync patterns still dominate many Matrix workloads.

Dendrite release 0.15.2 is shown as the latest release in its official release list during this review. The 0.15 series includes fixes around room version 12 and reliability issues, which is also a reminder that beta software can move quickly. Review the official Dendrite releases before upgrading or deploying.

Choose Dendrite when

• You specifically want to run a Go-based Matrix homeserver.
• You are comfortable validating client, federation, bridge, and admin-tool behavior before committing.
• You can tolerate Beta maturity in exchange for a different implementation architecture.

Action: stage Dendrite with the exact clients and appservices you plan to use. A feature checklist is more useful than a synthetic “lighter than Synapse” claim.

Conduit: simple Rust deployment with a smaller-scope mindset

Conduit is a Rust Matrix homeserver whose stated goal is to be efficient, easy to set up, and usable even on small computers such as a Raspberry Pi. The project is active on its official GitLab repository, and the Matrix ecosystem directory labels it Beta.

Conduit is the most obviously “lightweight-oriented” project in this three-way comparison, but its own documentation is careful about status: most Matrix rooms work, yet not every feature is implemented and users may encounter bugs. The official Conduit introduction lists current limitations, so administrators should check that page rather than relying on an old feature matrix.

Storage and operational footprint

Conduit’s generic deployment documentation currently recommends RocksDB or SQLite. That is materially different from the PostgreSQL-centered production guidance for Synapse and the documented Dendrite Docker setup. For a small server, avoiding a separate PostgreSQL service can reduce the number of moving parts you maintain, back up, monitor, and update.

Conduit also provides native guidance for a simple systemd deployment behind a reverse proxy, plus Docker images. Its documentation covers federation, delegation, TURN, and appservices. That makes it a plausible fit for a family, small team, lab, or hobby server where simplicity is more important than maximum ecosystem coverage.

Choose Conduit when

• Your main priority is a compact, straightforward self-hosted deployment.
• You want Rust and an embedded database option instead of maintaining PostgreSQL.
• You have checked the documented missing features and know they do not block your intended use.
• You can test federation and appservices before relying on the server for critical communication.

Action: read the current limitations in Conduit’s official introduction and test your largest federated rooms before moving real users. Federation behavior is where “small server” assumptions are most likely to be challenged.

Feature maturity matters more than idle RAM

If you are choosing for production, the maturity labels provide a useful first filter. Synapse is Stable; Dendrite and Conduit are Beta. Beta does not mean unusable, and Stable does not mean resource-free. It means the risk profile is different.

A lightweight server that lacks one feature you need can cost more administrator time than a heavier server that works predictably. Examples include bridge behavior, application services, account administration, newer room versions, federation edge cases, moderation workflows, and upgrade tooling. These are workload and integration questions, not programming-language questions.

Practical decision checklist

• Pick Synapse if your first priority is mature compatibility and an established scale-out path.
• Evaluate Dendrite if you prefer Go and are prepared to run a beta homeserver with PostgreSQL-backed deployment.
• Evaluate Conduit if a simple Rust server with RocksDB or SQLite is attractive and its documented feature gaps are acceptable.
• Do not choose by idle RAM alone. Test room joins, initial sync, federation catch-up, media, and the bridges you actually use.
• Measure storage growth. Large rooms and media can turn disk usage into the bigger constraint even when CPU and RAM look fine.
• Plan backups before migration. A Matrix server name becomes part of user IDs and room identities, so replacing a homeserver is not the same as swapping a stateless web service.

Bottom line

For most administrators who want the least protocol and integration risk, Synapse is still the default recommendation. It is the only Stable option among these three in the official Matrix directory, it has extensive documentation, PostgreSQL production guidance, and a documented worker architecture for larger deployments.

Dendrite is the middle path: a maintained Go implementation with an appealing architecture, but still officially Beta. It is best treated as something to validate against your exact clients and integrations rather than as an automatic drop-in “lighter Synapse.”

Conduit is the most natural candidate when “lightweight” means fewer supporting services and a compact self-hosted footprint. Its RocksDB/SQLite deployment model and Rust implementation are attractive for small systems, but the Beta label and documented missing features mean compatibility testing is essential.

There is no verified universal winner for RAM, CPU, or disk across all Matrix workloads. The practical winner is the server that meets your required feature set on the smallest operational footprint you can reliably maintain.