マトリックスシナプス vs デンドライト vs コンジット：軽量サーバーの比較

Matrixホームサーバーを選ぶ際には、バイナリサイズが最小のサーバーを探すことよりも、許容できる運用上のトレードオフを選択することが重要です。Synapse、Dendrite、ConduitはいずれもMatrixに対応していますが、成熟度、実装言語、データベースモデル、スケーリングパス、管理者が許容できる互換性リスクの程度が異なります。2026年10月5日現在、公式のMatrixサーバーディレクトリでは、Synapseは安定版、DendriteとConduitはベータ版と記載されています。この成熟度の違いは、「軽量」という漠然とした主張よりも、はるかに重要な意味を持ちます。

この実用的な比較は、現在文書化され検証可能な情報に焦点を当てています。プロジェクトが、同一のユーザー、会議室、フェデレーショントラフィック、メディア負荷、データベースチューニング、およびハードウェア条件下で、3つの要素すべてを公平に代表する単一の制御されたベンチマークを公開していないため、普遍的なRAMまたはCPUの勝者を主張するものではありません。

簡単な比較：どのサーバーがどの用途に適しているか？

ソースの確認：公式のMatrixホームサーバーディレクトリ、Synapseのインストールドキュメント、Dendrite Dockerのインストールドキュメント、およびConduitの汎用デプロイメントドキュメントを参照してください。

Matrixホームサーバーにとって「軽量」とは実際には何を意味するのか

「軽量」とは、少なくとも4つの異なる意味を持ちます。アイドル状態のメモリ使用量、同期やフェデレーション中のCPU使用率、ストレージ容量の増加、または管理者が実行しなければならないサポートサービスの数です。これらの指標によって、最適なサーバーは異なります。少数のプライベートルームに参加するシングルユーザーのホームサーバーと、大規模なパブリックルームに参加し、複数のネットワークをブリッジし、何年分ものメディアを保存し、フェデレーションに積極的に参加するサーバーでは、動作が大きく異なります。

そのため、リソース要求は、展開環境と一致する再現可能なベンチマークによって裏付けられていない限り、ワークロードに依存するものとして扱うべきです。最も有効な対策は、まず想定されるワークロードを定義することです。具体的には、ローカルユーザー数、参加予定の最大ルーム数、フェデレーションの有効化の有無、ブリッジまたはアプリケーションサービスの必要性、想定されるメディア量、高可用性の必要性などです。

Synapse：最も安全で互換性を最優先した選択肢

Synapseは、最も幅広い運用実績を求める場合に、依然として信頼できる選択肢です。Matrix.orgはSynapseを安定版と評価しており、Elementは現在のリポジトリを積極的にメンテナンスしています。このレビューの時点で、GitHubで公開されている最新の安定版リリースはSynapse 1.162.0で、2026年9月29日にリリースされました。最新のリリース情報は、Synapseの公式リリースページで確認できます。

Synapseはしばしば「重い」と評されますが、それには背景説明が必要です。このプロジェクトは、リクエストのパフォーマンスを向上させるために、意図的にキャッシュをメモリに保持しています。管理者向けFAQには、アーキテクチャが大量のRAMを消費する可能性があることが明記されています。インストールガイドにも、大規模な公開ルームに参加する場合は、少なくとも1GBの空きRAMが必要だと記載されています。これは計画を立てる上での目安であり、小規模なプライベート環境における必須要件ではありません。

データベースとスケーリングモデル

SynapseはSQLiteで起動することもできますが、公式のインストール手順書では、ほぼすべてのインストールでPostgreSQLを使用すべきであり、本番サーバーにはSQLiteを使用すべきではないとされています。これは、「簡単な単一ファイルデータベース」という利点が、Synapseを長期運用向けに適切に導入するとほぼ失われるため、重要な点です。

Synapseは、3つの中で最も明確なスケールアウト方法を提供しています。小規模なインストールではモノリスとして実行でき、大規模なインストールではワーカーと呼ばれる複数のプロセスに処理を分割できます。現在のSynapseワーカーのドキュメントでは、ワーカーのデプロイメントはPostgreSQLを共有し、クライアントとフェデレーションのワークロードをプロセス間で分割できることが説明されています。これにより運用上の複雑さは増しますが、1つのプロセスでは不十分になった場合に明確な解決策が提供されます。

Synapseを選択する場合

• この比較では、最も成熟した選択肢を選ぶ必要があります。
• ブリッジ、アプリケーションサービス、管理ツール、あるいはあまり一般的ではないMatrixの機能を使用することを想定しており、互換性の問題による予期せぬトラブルを最小限に抑えたいと考えている。
• あなたはPostgreSQLを本番環境で運用する意思がある。
• 最終的には、ワーカーベースのスケーリングが必要になるかもしれません。

対策：リソース使用量だけがSynapseを拒否する理由である場合は、リソース使用量が大きすぎると決めつける前に、実際のワークロードでPostgreSQLを使用してテストしてください。アイドル状態のメモリ使用量だけでは、フェデレーションのパフォーマンスや大規模ルームでの動作を適切に判断することはできません。

Dendrite：Go言語ベースの代替案だが、まだベータ版である。

Dendriteは、Go言語で書かれた第2世代のMatrixホームサーバーとして開発されました。旧matrix-orgリポジトリは2024年11月にアーカイブされましたが、これはDendriteが消滅したことを意味するものではありません。開発はElement Dendriteリポジトリに移行し、現在も活発に開発が続けられています。公式のMatrixサーバーディレクトリでは、Dendriteは依然としてベータ版として扱われています。

この区別は重要です。なぜなら、古い記事では読者に正反対の2つの誤解を抱かせる可能性があるからです。1つはDendriteが開発中止になったというもの、もう1つはSynapseに取って代わったというものです。2026年10月現在、どちらも正確ではありません。Dendriteはメンテナンスされていますが、公式にはベータ版のままです。

導入およびデータベースに関する考慮事項

DendriteのDocker Composeのドキュメントでは、依存関係としてPostgreSQLを使用し、ホームサーバーをモノリス構成で実行します。これにより、リバースプロキシ、Dendrite、PostgreSQL、および一般的なMatrix DNS/TLS設定という、基本的な本番環境向けアーキテクチャが理解しやすくなります。

DendriteのGo実装は、コンパイル済みバイナリとGoの運用エコシステムを好む管理者にとって魅力的です。しかし、言語の選択だけでは、実際のリソース消費量の削減を保証するものではありません。フェデレーション状態解決、ルームサイズ、メディア、データベース動作、クライアント同期パターンは、依然として多くのMatrixワークロードにおいて重要な要素となっています。

このレビュー期間中、Dendriteの公式リリースリストには最新リリースとして0.15.2が表示されています。0.15シリーズには、ルームバージョン12周辺の不具合修正や信頼性の問題修正が含まれていますが、ベータ版ソフトウェアは急速に進化する可能性があることを改めて認識させられます。アップグレードやデプロイを行う前に、 Dendriteの公式リリースをご確認ください。

Dendriteを選ぶ場合

• あなたは具体的に、Go言語ベースのMatrixホームサーバーを運用したいと考えているのですね。
• コミットする前に、クライアント、フェデレーション、ブリッジ、および管理ツールの動作を検証することに抵抗がない。
• 異なる実装アーキテクチャを採用する代わりに、ベータ版レベルの成熟度を許容することは可能です。

対策：使用予定のクライアントとアプリサービスを正確に設定して、Dendriteをステージングしてください。「Synapseより軽量」といった漠然とした主張よりも、機能チェックリストの方がはるかに役立ちます。

Conduit：より小規模な視点に基づいたシンプルなRustデプロイメント

Conduitは、効率的でセットアップが容易、そしてRaspberry Piのような小型コンピュータでも使用できることを目標としたRustベースのMatrixホームサーバーです。このプロジェクトは公式のGitLabリポジトリで活発に活動しており、Matrixエコシステムディレクトリではベータ版として分類されています。

Conduitは、この3つのプロジェクトを比較した中で、最も明らかに「軽量化志向」のプロジェクトですが、その公式ドキュメントでは現状について慎重な姿勢を示しています。ほとんどのMatrixルームは動作しますが、すべての機能が実装されているわけではなく、ユーザーはバグに遭遇する可能性があります。Conduitの公式紹介ページには現在の制限事項が記載されているため、管理者は古い機能マトリックスに頼るのではなく、そのページを確認する必要があります。

保管および運用上のフットプリント

Conduitの一般的な導入ドキュメントでは、現在RocksDBまたはSQLiteの使用を推奨しています。これは、PostgreSQLを中心としたSynapseの運用ガイドラインや、DendriteのDockerセットアップに関するドキュメントとは大きく異なります。小規模サーバーの場合、PostgreSQLサービスを別途用意しないことで、保守、バックアップ、監視、更新が必要な要素の数を減らすことができます。

Conduitは、リバースプロキシの背後にシンプルなsystemd環境を構築するためのネイティブなガイダンスに加え、Dockerイメージも提供しています。ドキュメントでは、フェデレーション、デリゲーション、TURN、およびアプリケーションサービスについて解説しています。そのため、エコシステムの網羅性よりもシンプルさが重視される、家族、小規模チーム、ラボ、または趣味のサーバーなどに最適です。

配管を選択する場合

• あなたの最優先事項は、コンパクトで分かりやすい、セルフホスティング型の導入環境を構築することです。
• PostgreSQLを保守する代わりに、Rustと組み込みデータベースのオプションを使いたいのですね。
• 記載されている不足機能を確認し、それらが意図した使用を妨げないことをご理解いただいている。
• サーバーに重要な通信を依存させる前に、フェデレーションとアプリケーションサービスをテストすることができます。

対策： Conduitの公式紹介文に記載されている現在の制限事項をよく読み、実際のユーザーを移行する前に、最大規模のフェデレーションルームでテストを実施してください。フェデレーションの動作は、「小規模サーバー」という前提が覆される可能性が最も高い部分です。

機能の成熟度は、アイドル状態のRAMよりも重要である。

本番環境での使用を想定している場合、成熟度ラベルは有用な最初のフィルターとなります。Synapseは安定版、DendriteとConduitはベータ版です。ベータ版だからといって使用できないわけではなく、安定版だからといってリソースが不要というわけでもありません。リスクプロファイルが異なることを意味します。

必要な機能が一つ欠けている軽量サーバーは、動作が安定している高性能サーバーよりも管理者の時間を多く消費する可能性があります。例としては、ブリッジの動作、アプリケーションサービス、アカウント管理、新しいルームバージョン、フェデレーションの特殊なケース、モデレーションワークフロー、アップグレードツールなどが挙げられます。これらはワークロードと統合に関する問題であり、プログラミング言語に関する問題ではありません。

実践的な意思決定チェックリスト

• 成熟した互換性と確立されたスケールアウトパスを最優先事項とするなら、Synapseを選択してください。
• Go言語を好み、PostgreSQLをバックエンドとするベータ版ホームサーバーを運用する準備ができている場合は、Dendriteを評価してみてください。
• RocksDBまたはSQLiteを備えたシンプルなRustサーバーが魅力的であり、ドキュメントに記載されている機能の不足が許容範囲内であれば、Conduitを評価してください。
• アイドル状態のRAM容量だけで選ばないでください。テストルームへの参加、初期同期、フェデレーションの追いつき、メディア、そして実際に使用するブリッジも考慮してください。
• ストレージ容量の増加を測定しましょう。広い部屋や大量のメディアを使用すると、CPUとRAMに問題がなくても、ディスク使用量が大きな制約要因となる可能性があります。
• 移行前にバックアップを計画してください。Matrixサーバー名はユーザーIDとルームIDの一部となるため、ホームサーバーの交換はステートレスなWebサービスの交換とは異なります。

結論

プロトコルや統合のリスクを最小限に抑えたいほとんどの管理者にとって、Synapseは依然としてデフォルトの推奨オプションです。公式のMatrixディレクトリにある3つのオプションの中で唯一安定版であり、豊富なドキュメント、PostgreSQLの本番環境向けガイダンス、大規模デプロイメント向けのドキュメント化されたワーカーアーキテクチャを備えています。

Dendriteは中間的な選択肢です。魅力的なアーキテクチャを備えた、メンテナンスが行き届いたGo言語の実装ですが、公式にはまだベータ版です。そのため、そのまま「軽量版Synapse」として組み込むのではなく、実際のクライアントや統合環境で検証するのが最適です。

Conduitは、「軽量」がサポートサービスの削減とコンパクトなセルフホスト環境を意味する場合、最も有力な候補となる。RocksDB/SQLiteのデプロイメントモデルとRustによる実装は小規模システムにとって魅力的だが、ベータ版であることと、ドキュメントに記載されている未実装機能があるため、互換性テストは不可欠である。

すべてのMatrixワークロードにおいて、RAM、CPU、ディスクのいずれにおいても、普遍的に最適な選択肢は存在しません。実用的な観点から言えば、必要な機能セットを満たしつつ、運用上の負担を最小限に抑え、かつ安定的に保守できるサーバーこそが、真の勝者と言えるでしょう。