MongoDB と PostgreSQL：2026年の正しいデータベースの選び方

この比較をどう考えるか

問題は「どちらが最高か」ではなく「このワークロードとチームにどちらが合うか？」です。MongoDB と PostgreSQL はどちらも成熟した広く採用されたデータベースですが、デフォルトの最適化が異なります：MongoDB は柔軟なドキュメント型データと迅速なイテレーション、PostgreSQL はリレーショナルなモデリング、SQL の表現力、強い整合性保証に向いています。

アプリケーションの形から始める

選択が最も重要になるのはワークロードが明確に片方寄りのときです：

• コンテンツやプロダクトカタログ（ネストした属性、進化するフィールド、形が多様）
• SaaS のコアデータ（アカウント、請求、権限、監査ログ、多対多の関係）
• 分析とレポーティング（複雑なフィルタ、グルーピング、アドホッククエリ）
• イベント／アクティビティストリーム（高い書き込み率、時間ベースのクエリ、保持ポリシー）

有益なメンタルモデル：データが「関係を持つエンティティの集合」であれば PostgreSQL が簡単にフィットすることが多い。データが「形が変わる自己完結型のレコードの集合」であれば MongoDB が初期の摩擦を減らすことができます。

一貫した評価基準を使う

実務的に比較するには、同じ問いで両方を評価します：

• データモデル適合度：ドキュメント vs テーブル、形の変更頻度
• クエリ要件：ジョイン、集約、検索、レポーティング
• 整合性：制約、参照ルール、バリデーション期待値
• 一貫性／トランザクション：許容できる障害とできないこと
• パフォーマンスの駆動要因：読み取り／書き込みパターン、インデックス、ホットスポット
• スケーリング／可用性：レプリケーション、フェイルオーバー、運用の複雑さ
• チームスキル：SQL の熟練度、ツール群、マイグレーション体制

「両方」も選択肢に入れる

多くのチームは ポリグロット永続化 を採用します：PostgreSQL をソース・オブ・レコードにし、MongoDB をコンテンツやキャッシュ的な読み取りモデル、イベント中心の機能に使うことがあります。重要なのは、最も重要な部分で妥協を減らすことであり、イデオロギー的な純粋さではありません。

新サービスを素早く作る場合、早期にロックインしないプラットフォームとアーキテクチャを選ぶのは有効です。例えば Koder.ai（チャットからフルスタックアプリを生成するプラットフォーム）は React + Go + PostgreSQL をデフォルトにしており、トランザクションが重要なシステムの「安全なデフォルト」になります。一方で JSONB などで半構造化フィールドも許容できます。

データモデル：ドキュメント vs テーブル

データモデルのレベルでは、MongoDB と PostgreSQL はアプリケーションの“形”について異なる思考を促します。MongoDB はドキュメントデータベースで、コレクションに自己完結型の JSON ライクなドキュメントを格納します。PostgreSQL はリレーショナルデータベースで、テーブルに行を格納しキーで関連付け、関係を横断してクエリします。

データの表現方法

MongoDB では典型的なレコードが関連データを埋め込むことがあります：

• orders コレクション
  • 1つのドキュメントが注文と行アイテムの配列、配送先をまとめて持つ

これは、階層的または「アグリゲート」データで全体を一度に取得することが多い場合に合致します。

PostgreSQL では通常そのデータを正規化します：

• orders（注文ごとに1行）
• order_items（注文ごとに複数行）
• addresses（必要なら別テーブル）

この構造は、顧客、商品、注文を横断したレポーティングなどで強みを発揮します。

スキーマの柔軟性と強制

MongoDB はデフォルトで柔軟です：同じコレクション内のドキュメントが異なるフィールドを持てます。これがイテレーションを早めますが、バリデーションルールと運用上の規律がないと不整合な形が混入しやすくなります。

PostgreSQL はカラム型、制約、外部キーで構造を強制します。変更はマイグレーションを必要としますが、データ整合性の強いガードレールを得られます。

中間の道もあります：PostgreSQL の JSONB を使えばリレーショナルテーブル内に半構造化データを格納できます。多くのチームは安定したフィールド（ID、タイムスタンプ、ステータス）を通常カラムに置き、進化する属性を JSONB に入れることで、関係整合性を保ちつつ変化に対応しています。

どちらのモデルが輝くか

MongoDB はネストしたオブジェクト、イベントペイロード、ドキュメント単位で読むコンテンツライクなデータに自然に感じられることが多いです。PostgreSQL は関係性が第一級で、ジョインが頻繁に発生し、制約がモデルの一部である場合に優れます。

クエリ：SQL、集約、ジョイン

クエリ周りは日々の感触に最も影響します：PostgreSQL はテーブル間の集合演算に最適化され、MongoDB はネストしたアプリケーション形のドキュメントを扱うことに最適化されています。

SQL と MongoDB のクエリ／集約モデル

PostgreSQL の SQL は宣言的で合成可能です：結果セットを記述するとプランナーが実行計画を決めます。これにより複雑なフィルタ、グルーピング、ウィンドウ関数、CTE、マルチステップ変換が扱いやすくなります。

MongoDB は単純な取得に find を使い、変換には Aggregation Pipeline（filter → project → group → sort など）を用います。パイプラインは表現力がありますが順序に依存する手続き的な側面が強く、非常に複雑になると単一の SQL ステートメントより読みづらくなることがあります。

ジョイン：リレーショナルな結合 vs 埋め込みと $lookup

PostgreSQL はジョインを第一級ツールとして扱います。データを正規化してもクエリの書き方を変えずに横断できますが、ジョインのカーディナリティ、インデックス、チューニングを考える必要があります。

MongoDB はよく一緒に読まれるデータを埋め込むことを奨励します（例：行アイテムを含む注文）。これによりジョインが不要になり読み取りが簡素化されますが、重複や更新の複雑化が欠点です。

クロスコレクション関係が必要な場合、MongoDB は集約で $lookup を提供します。使えますが、よくチューニングされたリレーショナルジョインほど操作が楽で一貫した性能を出すのは難しいことが多いです。

レポーティングとアドホック分析

BIスタイルのワークロードでは PostgreSQL に軍配が上がることが多い：アドホッククエリ、探索的なジョイン、エンティティ横断のレポーティングが素直に書け、ほとんどの分析ツールが SQL をネイティブに話します。

MongoDB はレポートがドキュメント境界に沿っている場合は対応できますが、多エンティティの分析はパイプライン作業やデータウェアハウスへの ETL を必要とすることが多いです。

ドライバサポートと開発者体験

どちらも成熟したドライバがありますが感触は異なります。PostgreSQL は巨大な SQL ツール群、ORM、クエリアナライザの恩恵を受けます。MongoDB はドメインオブジェクトが既に JSON ライクであればコード中でより自然に感じられることが多いですが、関係性やレポーティング要件が増えると扱いが難しくなることがあります。

スキーマ設計とデータ整合性

スキーマ設計は両者が日常で最も異なる点です：MongoDB はアプリケーションオブジェクトのようにデータを形作るのに最適化され、PostgreSQL は関連する事実の集合のようにデータを形作るのに最適化されています。

正規化 vs 埋め込み（なぜ重要か）

PostgreSQL では正規化がデフォルトです：エンティティをテーブルに分割し、外部キーでつなぎます。これにより重複が減り、横断的な更新（顧客名の変更など）が安全になります。

MongoDB では埋め込みが一般的です：関連データを単一ドキュメント内に保存して1回のラウンドトリップで読み取れるようにします。例：注文ドキュメントが行アイテムを埋め込む。

トレードオフは更新と整合性のコストです。埋め込みは参照データ（商品名、価格スナップショット）を重複させることになりがちで、重い正規化は多くのジョインやチャッティな API を生みます。

要件の進化とスキーマ変更

要件が進化したとき（複数配送先の追加、任意の税フィールドの導入、新商品属性の追加など）、MongoDB の柔軟なドキュメントはアップフロントのマイグレーションを少なく吸収できます。

PostgreSQL もスムーズに進化できますが、変更は明示的です：ALTER TABLE、バックフィル、制約の強化など。多くのチームは「まずは NULL 許容、後で制約を厳しくする」というアプローチで素早く出荷し、長期的整合性を確保します。

制約 vs アプリケーション側のバリデーション

PostgreSQL の組み込みガードレール（外部キー、CHECK、一意制約）はデータベースに不正状態が入るのを防ぎます。

MongoDB はアプリケーションでのバリデーションに依存することが多いですが、JSON Schema による検証も存在します。文化的な違いとして、PostgreSQL は不変条件を中央で強制することを奨励し、MongoDB を使うチームはコードパスとテストでそれを守る傾向があります。

一般的なモデリングの落とし穴

過度な埋め込みは非常に大きなドキュメント、ホットスポット（単一ドキュメントへの大量書き込み）、困難な部分更新を招きます。過度な正規化は過剰なジョイン、チャッティな API、パフォーマンスの驚きを招きます。

実用的な経験則：一緒に変化するデータは埋め込む；独立して変化するデータは参照する。

インデックスと検索機能

インデックスは実用的な議論が最も現れる場所です：「最適な」データベースはしばしばあなたの最も一般的なクエリに対して予測可能なレイテンシで答えられるものです。

コアなインデックス型と得意分野

PostgreSQL はデフォルトで B-tree インデックスを使い、等価検索、範囲、ソートなど幅広いワークロードに対応します。アクセスパターンに応じて専門的な選択肢もあります：GIN（配列や全文検索、特に JSONB と相性が良い）、GiST/SP-GiST（地理空間やカスタム型）、BRIN（時系列など大きく自然順序のあるテーブル）。

MongoDB も一般的なルックアップとソートに B-tree スタイルのインデックスを使い、追加でmultikey（配列向け）、2dsphere（地理空間）、text（基本的な全文検索）などがあります。

実務的に言えば：PostgreSQL は様々なデータ型や演算子向けの「インデックスプリミティブ」が豊富で、MongoDB はネストフィールドのインデックスを柔軟に扱える点で強みがあります。

複合インデックス、選択性、実際のクエリ形状

両システムとも 複合インデックス に大きく依存します。コアアイデアは同じ：フィルタに一緒に使うフィールドをインデックス化してエンジンが早期に絞り込めるようにすること。

• PostgreSQL では列の順序が重要で、可能なら最も選択性の高い先頭列を使います。部分インデックスは WHERE status = 'active' のような頻繁なフィルタに効果的です。
• MongoDB でも複合インデックスの順序は重要で、等価フィルタ、範囲フィルタ、ソートを混在させるときに特に留意が必要です。選択性の低いフィールドをインデックス化するのは落とし穴です。

テキスト検索：組み込みの基本機能 vs 専用検索ツール

両データベースとも組み込みの全文検索機能を持ちますが、複雑な検索体験（関連性、オートコンプリート、重いファセットなど）には専用の検索エンジンを使う方がクリーンです。

• PostgreSQL の全文検索は成熟しており GIN インデックスと相性が良いです。
• MongoDB の text インデックスは単純なキーワード検索には使えますが、ランク付けや言語処理、高度なアナライザでは制限があります。

実際のクエリで計測する（推測しない）

パフォーマンス評価では実際のクエリプランで検証してください。

• PostgreSQL：EXPLAIN (ANALYZE, BUFFERS) を使い、シーケンシャルスキャンや見積りの誤差、高コストなソートを探します。
• MongoDB：explain() を使い、ステージ出力（インデックス使用状況、docs examined vs returned）を確認します。

ここで「SQL と MongoDB クエリ言語」の議論は落ち着きます：勝つのは実際にアプリが実行するパスでの作業量を最も減らすインデックスです。

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

トランザクションは単なるチェック項目ではなく、アプリが障害をどのように耐えられるかを定義します。ACID は通常：原子性（Atomicity）、一貫性（Consistency）、分離（Isolation）、永続性（Durability）を意味します。

PostgreSQL："トランザクション第一"

PostgreSQL はマルチステートメント・マルチテーブルトランザクションを中心に設計されています。注文作成 → 在庫確保 → 決済 → 台帳書き込み のようなワークフローを一つの単位として安全にモデル化できます。制約、外部キー、トリガーなど成熟した機能が不変条件を支えます。

並行性については PostgreSQL は MVCC を使います：リーダーはライターをブロックせず、その逆も同様です。隔離レベル（Read Committed, Repeatable Read, Serializable）でどの程度の異常を防ぐかを選べます。これは複雑なビジネスルールを持つ書き込み負荷の高いシステムで重要です。

MongoDB：強力な選択肢だが設計に影響

MongoDB はデフォルトで 単一ドキュメントの原子性 を提供し、関連データを埋め込めれば更新は安全です。また マルチドキュメントトランザクション（レプリカセットやシャードクラスタでも可）をサポートしますが、オーバーヘッドや実務的制約（トランザクションサイズや時間制限、ロックや調整コストの増加）があります。

MongoDB の整合性は read concern や write concern で設定可能です。多くのアプリは majority 書き込みなどを使い、フェイルオーバー後のロールバックを避けます。

計画すべきエッジケース

マルチエンティティ操作で差が出ます：

• MongoDB：ドキュメント横断の更新は可能ですが、多くのチームは埋め込み、冪等な書き込み、補償アクションのパターンを好みます。
• PostgreSQL：マルチテーブルの不変条件や複雑な更新が日常的で、制約がエラーを早く検出します。

コアワークフローが複数レコードにまたがる厳密な不変条件に依存するなら、PostgreSQL の方が単純に感じられることが多いです。ドキュメント内に重要な更新を収められる、または最終的な整合性で十分な場合は MongoDB がフィットします。

パフォーマンス：何が速度を決めるか

MongoDB と PostgreSQL の性能差はエンジンの速さよりも、データモデルがアクセスパターンにどれだけ合っているか、1リクエストあたりにデータベースがどれだけの作業を強いられるかで決まることが多いです。

ワークロードの形状：読み取り重視、書き込み重視、混合

読み取り重視のシステムはラウンドトリップやサーバ側の重い処理を最小化する設計に報います。MongoDB はリクエストが単一ドキュメントの取得や狭いインデックス範囲スキャンにマッピングされると非常に高速です（ドキュメントが過大でない前提）。

書き込み重視ではインデックスの保守、書き込み増幅、永続化設定がボトルネックになります。PostgreSQL は狭い行幅、適切なインデックス、バッチ書き込みで非常に良い性能を出せます。MongoDB も追記パターンでは得意ですが、大きなドキュメントの頻繁なインプレース更新はコストになります。

混合ワークロードは競合を露呈します：ホットインデックスの更新、ロック圧、キャッシュの喪失など。ここでは両者とも「1リクエストあたりの余計な作業」を減らす（不要なインデックス、広いプロジェクション、チャッティなクエリの削減）が有効です。

レイテンシ vs スループット（公平にベンチする方法）

低い p99 レイテンシは通常平均ではなく遅いクエリによって支配されます。スループットは並行時にデータベースが CPU、メモリ、I/O をどれだけ効率的に使うかで決まります。

公平なベンチマークにするには：

• 同じデータセットサイズ（インデックス含む）を RAM に対して同等に保つ
• 耐久性／整合性設定（fsync、ジャーナリング、同期レプリケーション）を揃える
• ジョインと埋め込みの意味を等価にする（クエリセマンティクスを揃える）

一般的なパフォーマンス駆動要因

ジョイン vs ドキュメント取得： PostgreSQL のジョインは強力ですが、良い結合キーと選択的な述語がないと大規模で高コストになります。MongoDB は埋め込みでジョインを回避できますが、データ複製によりコストを払うことがあります。

ドキュメント／行のサイズ： MongoDB はドキュメントが大きくて多くのクエリが一部だけを必要とする場合に性能が低下します。PostgreSQL でも幅の広い行や大きな JSONB ブロブは I/O とメモリ圧迫を招きます。

インデックス保守： インデックスが多いほど読み取りは良くなりますが、書き込みに対するコストも増えます。両システムとも実際のクエリに紐づいたインデックスだけを持つべきです。

最小限かつ代表的な負荷テストを構築する

上位 5〜10 のエンドポイント／クエリを現実的な同時実行とデータ分布で再生する小さなハーネスを作ります。ベースラインを取得し、1つずつ要素（インデックスセット、埋め込み、JSONB vs 正規化テーブル）を変えていきます。チェックリストをリポジトリに残し、合成単一クエリのベンチに頼り切らないでください。

スケーリングと高可用性

HA とスケーリングは単なる「レプリケーションをオンにする」チェックではなく、スキーマ、クエリパターン、運用負荷に影響する設計選択です。成長に向けて最速の道は、主要なアクセスパターン（読み取り重視、書き込み重視、時系列、マルチテナント）とスケーリングメカニズムを揃えることです。

レプリケーションとフェイルオーバーの期待値

MongoDB はレプリカセットをよく使います：1つのプライマリが書き込みを受け、セカンダリが oplog を複製し、障害時に選挙で新しいプライマリを立てます。計画すべき点：

• 選挙時間とフェイルオーバー中の一時的な書き込みエラー
• 書き込み保証（例：majority）がレイテンシと耐久性をトレードオフする
• リードプリファレンスによりやや古いデータを返す可能性

PostgreSQL は通常ストリーミングレプリケーション（物理）を使い、プライマリとスタンバイが一般的です。フェイルオーバーはツール（マネージドサービス、Patroni など）でオーケストレーションされ、トレードオフは：

• 同期 vs 非同期レプリケーション（コミットレイテンシ vs フェイルオーバー時のデータ喪失可能性）
• RPO/RTO はフェイルオーバー自動化とテスト頻度に強く依存

水平スケーリング：シャーディング vs パーティショニング

MongoDB のシャーディング は組み込みで読み書きをシャードに分散できます。代償は運用の複雑さ：シャードキーの選択、ホットスポット回避、チャンク移動、クロスシャードクエリのコスト理解。

PostgreSQL は垂直（スケールアップ）に非常に強く、水平（スケールアウト）はより選択的です。一般的なパターン：

• リードスケーリング：レプリカを利用
• ライトスケーリング：
  • パーティショニング（ネイティブ）：時系列やテナントベースに有効だが自動で書き込み負荷を分散するわけではない
  • シャーディングソリューション：有効だが可動部が増え、シャード間のジョインやトランザクションに制約を与えることが多い

アクセスパターンに合わせて成長を計画する

コミットする前に将来のクエリをモデル化してください：どのフィールドでフィルタするか、どのソートが必要か、何をトランザクショナルに保つ必要があるか。今日合う設計でも、クロスシャードのファンアウトやホットパーティション、過度に同期的なレプリケーションを強いると予想より早くボトルネックになります。

運用：バックアップ、監視、保守

運用は「MongoDB vs PostgreSQL」が機能の話から習慣の話になるところです：どのようにバックアップし、どれくらい早く復旧できるか、バージョンを変えるときにどれだけ自信を持てるか。

バックアップ、復元、RPO/RTO

PostgreSQL は論理バックアップと物理バックアップのミックスをよく使います：

• 論理：pg_dump/pg_restore は柔軟（テーブル単位復元、移植性）が高いが大規模では遅いことがある。
• 物理 + PITR：ベースバックアップ（pg_basebackup 等）と WAL アーカイブでポイントインタイム復旧が可能。低い RPO（数分以内）と予測可能な RTO を目指すなら一般的な路線。

MongoDB はツールとスナップショット戦略でこれに対処します：

• 論理：mongodump/mongorestore は簡単だが大規模や厳しい RTO で苦戦することがある。
• スナップショット + oplog：ファイルシステムやマネージドなスナップショットと oplog 再生でポイントインタイム復旧をサポートできる（適切に構成された場合）。

どちらでも RPO/RTO を明確に定義し、復元手順を定期的にテストしてください。「バックアップ済みだが復元したことがない」では意味がありません。

監視で見るべきシグナル

ユーザーの痛みに強く相関する症状を監視します：

• 遅いクエリ：PostgreSQL の pg_stat_statements、auto_explain、スロークエリログ；MongoDB の profiler とスロークエリログ
• ロッキング／競合：PostgreSQL のロック待ち、デッドロック、長時間トランザクション；MongoDB のロック指標や書き込み競合
• レプリケーション遅延：両方で読み取りスケーリングやフェイルオーバーの正しさに重要

ストレージヘルスも追跡します：PostgreSQL の vacuum 進捗とブロート、MongoDB のキャッシュ逸脱、ページフォルト、インデックスビルドの影響など。

アップグレード、マイグレーション、定期保守

PostgreSQL のメジャーアップグレードは pg_upgrade や論理レプリケーションのカットオーバーを伴うことが多く、拡張互換性とダウンタイムを計画します。MongoDB のアップグレードは通常ローリングで行い、Feature Compatibility Version（FCV）、インデックスビルド、（シャード化されている場合の）チャンクバランスに注意します。

ツールと自動化の期待値

実務では多くのチームがマネージドサービス（Atlas やクラウドの Postgres）や Terraform/Ansible、Kubernetes オペレータによる自動化に頼ります。重要なのは「自動化できるか」ではなく、「チームがランブック、オンコールシグナル、復元ドリルを実行する準備ができているか」です。

Koder.ai のように複数環境を素早く生成するなら、運用のデフォルト（バックアップ戦略、マイグレーションワークフロー、ロールバック手順）を早めに標準化しておくと、速度が脆弱性につながるのを防げます。

セキュリティとガバナンスの考慮

セキュリティは「認証をオンにして終わり」ではありません。両データベースで実務的に重要なのは最小権限、資格情報のローテーション、誰がいつどのデータに触れたかを証明できるかです。

認証、ロール、日常的なアクセス制御

両方とも強力な認証と RBAC をサポートしますが実務の感触は異なります。

PostgreSQL のモデルはユーザー／ロール、スキーマ／テーブル／ビューへの付与に基づいており、アプリ（書き込み経路）とアナリスト（読み取り経路）を明確に分けるのにマッピングしやすいです。

MongoDB の RBAC も成熟しており、データベースやコレクション単位で権限を絞れます。サービス X がコレクション Y を読み書きできる、という考え方に合います。

両方で有効な最小権限パターン：

• ワークロードごとにロールを作る（例：app-write、app-read、analyst-read、admin-breakglass）
• BI ツールは読み取り専用にし、アドホックな書き込みは全て制限する
• 生データではなくビュー（Postgres）やキュレーション済みコレクション（MongoDB）に権限を付与する

転送中／保存時の暗号化

転送中の暗号化は TLS を必須扱いにしてください。ドライバ側とサーバ側で強制し、古いプロトコルは無効にします。

保存時暗号化はデプロイモデルによって異なります：

• 自前運用ならデータベース機能とディスクレベルの暗号化、キー管理を組み合わせる
• マネージドサービスを使う場合は「保存時暗号化」の意味、キー管理、カスタマーマネージドキー対応をプロバイダドキュメントで確認

監査、コンプライアンス、ガバナンス

SOC 2、ISO 27001、HIPAA、PCI などのコンプライアンスがあるなら、監査と保持の明確なストーリーが必要です：接続ログ、DDL 変更、権限変更、機微なテーブル／コレクションへのアクセス履歴など。ガバナンスはデータ分類（どれが PII か）、保持ポリシー、インシデント対応手順のドキュメント化も含みます。

実用的なアプローチは初期にどのイベントを捕捉するか（認証、管理操作、特定データセットへのアクセス）を決め、ログを SIEM に集中させることです。

シークレット管理と接続の衛生管理

多くの実際の侵害はクレデンシャル周りや接続の甘さから起きます。

• シークレットはシークレットマネージャに保管（設定ファイルや回転しない CI 変数は避ける）
• スタッフ変更や定期的に資格情報をローテーション
• サポートする場合は短期トークンや IAM ベースの認証を使う
• ネットワークアクセスを制限（プライベートネットワーク、IP アローレスト、公開露出しない）
• ドライバを最新に保ち、接続上限とタイムアウトを適切に設定してノイズとなる障害モードを避ける

適切に行えば、MongoDB も PostgreSQL も厳しいセキュリティとガバナンス要件を満たせます。違いは、どのモデルが組織のアクセスパターンと監査期待に合うかです。

コストと総所有コスト（TCO）要因

コストは単に「データベース代金」ではありません。MongoDB と PostgreSQL の TCO はリソース消費、耐久性オーバーヘッド、健全性を保つための人的コストに分かれます。

主要なコストドライバ

コンピュート が最大の変動要素であることが多いです。ジョインが多く複雑なレポートや厳密な整合性が求められると CPU/メモリの使い方が変わります。ストレージ コストは生データサイズだけでなくインデックスフットプリントや非正規化による重複にも依存します。

IOPS とレイテンシ はワーキングセットがメモリに収まらない場合やインデックスが大きい場合に目に見えるコストになります。高い書き込み率はバックアップオーバーヘッド（スナップショット頻度、WAL/oplog 保持、復元テスト）も増やします。レプリカはコストを乗じます：3ノードの HA は計算・ストレージをおおよそ3倍にし、クロスリージョンレプリカはネットワークと高いストレージクラスのコストを加えます。

ライセンスとサポート

PostgreSQL は一般にオープンソースライセンスで使われ、MongoDB はコミュニティ版か商用提供のいずれかで使われます。どちらのマネージドサービスを使うかで、スタッフ時間を単位価格に置き換えることができます。有償サポートはインシデント対応やチューニングで価値を生むことがありますが、その ROI はチームの経験とリスク許容度によります。

運用の複雑さ = 実コスト

運用努力は人件費と機会費用として現れます：スキーママイグレーション、インデックスチューニング、クエリ退行、キャパシティプランニング、オンコール疲弊、コンプライアンス作業。組織に既に強い PostgreSQL ツール群と標準、訓練を受けたエンジニアがいる場合、エンジンを切り替えるコストはインフラ請求額より高くなることが多く、その逆も然りです。

簡単なコストチェックリスト

• 想定される読み書きスループットとピーク対平均比
• 現在と 12–24 か月後のデータサイズ；インデックス成長の仮定
• 環境数（dev/stage/prod）とレプリカ数
• バックアップ／復元目標：RPO/RTO、保持、テスト頻度
• クロスリージョン要件とネットワーク転送量の見積もり
• マネージド vs 自前運用：スタッフ、オンコール、パッチ、アップグレード
• コンプライアンスニーズ（監査、暗号化、アクセス制御）

ユースケースガイドと意思決定マトリクス

ドキュメントデータベース vs リレーショナルデータベースの選択は通常、原始的な速度の話というよりも、データが変化する様子、どれだけ整合性を強制する必要があるか、チームがどのようにクエリしたいかに関する話です。

MongoDB が強く適合する場面

MongoDB は保存する“もの”がネストした JSON オブジェクトのように自然に見え、頻繁に進化するドメインで輝きます：

• 商品カタログ、コンテンツ管理、ユーザープロファイル、イベントペイロード、IoT テレメトリ、セッション／状態データ
• 任意フィールドが多く、スキーマ変更が頻繁、テナント固有の属性がある
• 関連データを埋め込んでジョインの多い読み取りを避けたいアプリケーション

PostgreSQL が強く適合する場面

PostgreSQL はリレーショナル整合性と表現力豊かな SQL が重要な場合に通常安全な選択です：

• システム・オブ・レコード：注文、請求、在庫、人事、財務、台帳
• 多対多関係や分析／レポーティングでジョイン、ウィンドウ関数、SQL ツールを多用する場合
• 外部キー、一意性、CHECK 制約など厳しい整合性と ACID トランザクションが必要な場合
• JSONB を使って半構造化データとリレーショナルテーブルを共存させる混在ワークロード

ハイブリッドアプローチが有効なとき

実用的な分担例：PostgreSQL に厳しい制約のある権威的エンティティを置き、MongoDB に柔軟なインタラクションやコンテンツドキュメントを置く。

例：注文・支払いは Postgres、商品説明やパーソナライズ用のブロブ、クリックストリームイベントやキャッシュ的プロジェクションは MongoDB。ID を不変化させ、アウトボックス／イベントパターンで同期し、エンティティごとにソース・オブ・トゥルースを決める。

クイック意思決定マトリクス

高速に出荷しつつ意思決定の手戻りを減らしたければ、強力なデフォルトを選びつつ出口戦略を残すとよい：コアエンティティは Postgres で始め、明確にドキュメント型領域だけを MongoDB に任せ、実クエリプランで検証する。

スイッチを計画する（または第2のストアを追加する）場合は /blog/database-migration-checklist を参照してマイグレーション作業を構造化してください。