【MongoDB vs PostgreSQL】結論：迷ったらPostgreSQL【技術選定】

MongoDBとPostgreSQLのどちらを使うべきか。

細かく比較し始めると、機能、性能、可用性、料金など、いくらでも論点は出てきます。ただ、実際の開発で重要なのは、扱うデータの形と開発・運用のしやすさです。

先に結論を書くと、複雑なリレーションや強い整合性が必要ならPostgreSQL、データをドキュメント単位で扱い、構造変更の多い開発を素早く進めたいならMongoDBが向いています。

どちらでも作れるシステムは多いので、最後はチームの経験や、Atlas、Neon、Amazon RDSといったマネージドサービスの使い勝手まで含めて決めればよいと思います。

前提

これはMongoDBやNoSQLに興味がある人向けの記事です。
当てはまらない人にとっては、MongoDBを選ぶ合理性は低いため、RDBを利用することを推奨します。

PostgreSQLはデータの関係を扱いやすい

PostgreSQLでは、データをテーブルに分け、外部キーやJOINを使って関係を表現します。

ユーザー、契約、請求、商品など、同じデータをさまざまな方向から参照するシステムには素直に合います。外部キー、UNIQUE制約、CHECK制約などを使い、データベース側で不正な状態を防ぎやすい点も強みです。

例えば、次のようなシステムならPostgreSQLを選びやすいでしょう。

• 複数テーブルをまたぐ検索が多い
• データ間の関係が複雑
• 決済や在庫など、複数データの整合性が重要
• 将来どのような検索が増えるか分からない

特に理由がなければPostgreSQLを選ぶ、という判断も妥当です。対応できる要件の範囲が広く、設計や運用に関する情報も豊富です。

MongoDBはデータのまとまりを扱いやすい

MongoDBでは、一緒に読み書きするデータを一つのドキュメントにまとめます。

例えば、問題文、選択肢、解説を一つの問題ドキュメントとして保存できます。画面の表示に必要なデータをまとめて取得でき、問題形式ごとに異なるフィールドを持たせることも簡単です。

次のようなデータにはMongoDBが合いやすいです。

• データの読み書き単位が明確
• 親子のデータを常にまとめて扱う
• 種類によってデータ構造が異なる
• 開発中にフィールドや構造が頻繁に変わる

一方、何でも埋め込めばよいわけではありません。子要素が際限なく増える、子要素だけを頻繁に検索する、複数ドキュメントをまたぐ更新が多い、といった場合は設計が苦しくなります。

MongoDBは変更を段階的に適用しやすい

MongoDBの実務上の大きな利点は、フィールドを追加するたびに、全データを一斉にマイグレーションしなくてもよいことです。

新しいドキュメントだけに新しいフィールドを保存し、古いドキュメントでは未設定として扱えます。必要なら、後からバッチ処理などで段階的に更新できます。

仕様変更の多い新規開発では、この手軽さはかなり大きな利点です。アプリケーションのデプロイと、既存データの更新を分けて進めやすくなります。

ただし、MongoDBならマイグレーションが完全になくなるわけではありません。フィールド名や型の変更、ドキュメント構造の大幅な変更ではデータ移行が必要です。また、古い形式をいつまでも残すと、アプリケーション側の分岐が増えていきます。

MongoDBはスキーマが存在しないのではなく、複数世代のスキーマを一時的に共存させやすいデータベースだと考えるほうが実態に近いでしょう。

PostgreSQLでもJSONは扱える

JSONを保存したいという理由だけでMongoDBを選ぶ必要はありません。PostgreSQLにはjsonbがあり、通常のカラムと柔軟なJSONデータを併用できます。

識別子や検索条件には通常のカラムを使い、種類ごとに異なる部分だけをjsonbに保存する方法もあります。この程度で要件を満たせるなら、PostgreSQLを使うほうが単純な場合もあります。

ただし、ほとんどのデータをjsonbへ詰め込むのであれば、PostgreSQLの制約やリレーションの利点を十分に使えません。その場合は、最初からMongoDBを使う選択肢も検討したほうがよいでしょう。

Atlas、Neon、RDSまで含めて考える

実際の選定では、MongoDBとPostgreSQLそのものだけでなく、利用するマネージドサービスの違いも無視できません。

MongoDB Atlasは、データの確認、インデックス管理、監視、バックアップなどが一つにまとまっています。MongoDBを使うならまず候補になるサービスで、インフラ専任者がいない開発でも扱いやすいと感じます。

PostgreSQLを手軽に使いたいならNeonがあります。小さく始めやすく、個人開発や新規サービスの初期段階では有力な選択肢です。

一方、AWSを中心にシステムを構成するならAmazon RDSが自然です。VPC、IAM、CloudWatchなどAWSの各サービスと組み合わせやすく、企業システムでも採用しやすい選択肢です。その代わり、NeonやAtlasより設定項目が多く、気軽さでは劣ると感じる場面もあります。

大まかには次のように考えられます。

ここで注意したいのは、MongoDBとPostgreSQLはデータベースの比較であり、Atlas、Neon、RDSはサービスの比較だということです。

まずデータの性質からMongoDBかPostgreSQLかを考え、その後で運用方法や料金からサービスを選ぶのが順当です。ただし、どちらでも問題なく作れる場合には、マネージドサービスの使い勝手を決め手にしてもよいと思います。

まとめ

複雑な関係、横断検索、強い整合性が中心ならPostgreSQLが向いています。

データを一つのまとまりとして扱い、構造の違いや変更に柔軟に対応したいならMongoDBが向いています。フィールド追加のたびに一斉マイグレーションを要求されないことや、Atlasの使いやすさも実務上は大きな利点です。

PostgreSQLを選ぶ場合も、手軽さを求めるならNeon、AWSとの統合や本番運用を重視するならRDSという選択肢があります。

結局のところ、絶対的に優れたデータベースがあるわけではありません。データの読み書き単位、整合性、構造変更の頻度、そして運用環境を見て、扱いやすいほうを選べばよいでしょう。