概要：ドキュメント対行

MongoDBはBSONドキュメントをコレクションにまとめて格納し、柔軟なスキーマを持ちます。PostgreSQLはテーブルに厳格な型付き行を格納し、必要に応じてJSONB列型でドキュメントデータベースのように振る舞えます。2026年時点で両者とも本番環境レベルで、適切な設定で巨大なワークロードを処理できます。

近年の興味深い発展は、PostgreSQLのJSONBが従来の「スキーマ柔軟性」のギャップを縮めたことです。主にJSONドキュメントを保存しつつ、後で厳格な列とリレーショナル整合性を追加できるアプリをPostgresで動かせます。これにより、従来MongoをデフォルトにしていたワークロードでもPostgresが真剣な代替手段となりました。

データモデリング

MongoDBは、データが自然にドキュメント形状である場合に優れています。例えば、ネストされた設定を持つユーザープロファイル、カテゴリごとに属性が異なるカタログアイテム、またはスキーマが常に進化するイベントログなどです。埋め込みドキュメントは結合の必要性を減らし、等価なリレーショナルスキーマよりも読み取りを高速化できます。

Postgresは、ユーザー、注文、請求書、製品などの自然な関係性があるデータに強いです。参照整合性、結合、テーブル間のトランザクション整合性が重要な場合に有効です。JSONB列型は、正規化されたスキーマ内で設定、メタデータ、ログなどの半構造化フィールドに対して逃げ道を提供し、両者の長所を兼ね備えます。

クエリ

SQLは標準化され、強力なクエリ言語です。多くのテーブルを横断した結合、ウィンドウ関数、CTE、再帰クエリ、複雑な集計を、ほとんどの開発者が既に知っている構文で実行できます。MongoDBの集計パイプラインは表現力豊かですが、冗長で非標準です。レポート作成やアドホック分析クエリでは、SQLが大きな生産性向上をもたらします。

MongoDBの強みは、ネストされたドキュメントをナビゲートすることにあります。深くネストされたフィールドをクエリしたり、特定のサブドキュメントを抽出したりする場合、PostgresのJSONBに対する演算子を叩くよりもMQLが自然です。

トランザクションと整合性

Postgresは最初から任意の行とテーブルに対してACID準拠です。MongoDBは4.0（2018）でマルチドキュメントACIDトランザクションを追加し、レプリカセットとシャードクラスターで信頼性が向上しましたが、Postgresのトランザクションよりもコストが高く、エラーが起きやすいです。アプリが本当にエンティティ間の整合性（銀行、在庫、複数ステップの注文）を必要とする場合、Postgresは依然として安全な基盤です。

スケーリング

MongoDBは初めから水平スケーリングを想定して設計されました。ネイティブシャーディングにより、複数ノードにコレクションを分散でき、運用オーバーヘッドが比較的低くなります。大量の書き込み量や数十テラバイト規模のデータを扱うワークロードでは、Mongoは実際の運用上の優位性を持ちます。

Postgresは垂直スケーリングが非常に優れています。大規模なマネージドインスタンスで膨大な負荷を処理できます。水平スケーリングは歴史的にCitus（拡張機能）、リードレプリカ、またはアプリ層での論理シャーディングが必要でした。Aurora PostgreSQLやCockroachDB（Postgres互換）などのマネージドサービスは、このギャップを大きく埋めています。

価格とマネージドサービス

MongoDB Atlasは、無料ティア（M0、512 MB）が充実しています。ペイドクラスターは共有で約$9/月から、専用クラスターは$57/月以上です。Postgresのマネージドオプションは多様で、Neonは無料ティアとスケール・トゥ・ゼロ価格、Supabase Proは$25/月、Amazon RDSやAuroraも同程度の価格帯です。趣味や小規模プロジェクト向けに、両エコシステムとも良い無料オプションがあります。

ライセンス

MongoDBはSSPL（Server Side Public License）を採用しており、OSI承認は受けていません。そのため、クラウドリセラーがMongoをサービスとして提供する際にリスクが伴います。これはアプリ開発者にはほとんど関係ありませんが、インフラ製品を構築する場合は重要です。Postgresの許容的なライセンスにはそのような制限はありません。

どちらを選ぶべきか？

関連比較