100万レコード超のトランザクショナルB2BアプリにおけるPostgresとMongoDBの比較
貴社のB2Bプロダクトは昨年、プロダクトマーケットフィットを達成しました。現在、プライマリデータベースには120万件のレコードがあり、ピーク時のレスポンスタイムは400msを超えつつあり、インフラ費用は先月倍増したところです。誤ったエンジンのチューニングにさらに一四半期を費やす前に、そもそも最初に正しいデータベースを選んでいたのか、あるいは今切り替えるほうが回避策をもう一年続けるよりも安く済むのかを問い直す価値があります。
「とりあえず選んでおけばよい」が静かに崩れ始める場所
Postgres と MongoDB の議論は古くからありますが、多くのチームは今でも感覚でこの選択を下しています。チーム内の誰かが Postgres を知っていた、あるいはチュートリアルが MongoDB を使っていた、それがそのままデフォルトになったというケースです。この選択は最初の10万レコード程度までは表面化しません。100万行を超え、数千人の同時ユーザーが利用するようになると、誤った選択のコストが遅いダッシュボード、週末の緊急対応、そしてエンジニアリングリードから提出される高額な再設計提案として現れ始めます。
両エンジンとも優れています。両者とも巨大な本番ワークロードを支えています。しかし、それぞれ異なるデータ形状と異なる保証を最適化しており、B2B のトランザクショナルアプリはまさに両者が乖離する軸に負荷をかけます。このクラスのアプリケーションで最も重要な4つのトレードオフは、一貫性、大規模時のクエリレイテンシ、保有コスト、そして変更コストです。
一貫性は好みではなく、ビジネスリスクである
トランザクショナルな B2B システム(請求書、注文、契約、在庫、給与計算)においては、データベースのデフォルトの一貫性モデルは好みの問題ではありません。それは、失敗したときに損益計算書に現れるビジネスリスクです。
Postgres は成熟したリレーショナルエンジンであり、強力な ACID 保証、本物の外部キー、そして標準で利用可能な直列化可能な分離レベルを備えています。請求サービスが請求書をコミットするとき、対応する明細行が存在すること、顧客クレジットがアトミックにデクリメントされたこと、同時読み取りが未完了の書き込みを目にできないことを保証できます。財務に関わるワークフローにとって、この正しさには対価を払う価値があります。
MongoDB はそのギャップの多くを埋めてきました。マルチドキュメントの ACID トランザクションは 4.0 以降、本番運用に耐える品質になっており、単一ドキュメントの書き込みは常にアトミックでした。しかしデフォルトは依然として、厳格な正しさよりも可用性と柔軟なスキーマを優先しています。マルチドキュメントトランザクションには測定可能なパフォーマンスコストが伴い、インデックスは意識的に保守する必要があり、スキーマドリフトは、悪いレポートが顧客の目の前でそれを暴くまで隠れていることがあります。
エンジニアリング上のトレードオフはビジネスリスクに直結します。顧客向けレポートに誤った数値が入ることで取引先を失うのであれば、デフォルトで正しさを強制するデータベースを選ぶべきです。ワークロードが大部分、追記専用のテレメトリやユーザー生成コンテンツで結果整合性が許容できるのであれば、この制約はそれほど重要ではありません。
100万レコード超におけるレイテンシ
両エンジンとも 100 万レコードをはるかに超えてスケールします。本当の違いは、それらを高速に保つためにどれだけの作業が必要かにあります。
Postgres は「退屈な」読み取りパターンで勝ります。境界のある結果セット、インデックス付き JOIN、予測可能なフィルタを備えた形の整ったクエリです。適切にインデックスされた Postgres テーブルは、数億行に達しても点参照を一桁ミリ秒で提供でき、クエリプランナは通常、雑に書かれたクエリからも回復できます。Postgres が苦手なのは、境界のないドキュメント読み取り、深くネストされた非正規化構造、そして極端にスキーマが変動するワークロードです。
MongoDB が勝つのは、アクセスパターンが本当にドキュメント形状である場合です。1つのクエリが API レスポンスに綺麗にマッピングされる1つのネストされたオブジェクトを返し、ホットパスに JOIN がない場合です。これによりネットワークラウンドトリップとシリアライゼーションのオーバーヘッドが排除されます。ただしこれが成り立つのは、初日にドキュメント境界を正しく設計していた場合に限られます。それらの境界が誤っていた場合(そしてしばしば誤っています。初期のプロダクト判断は推測だったからです)、MongoDB が最適化されていないクロスコレクションのルックアップに行き着き、レイテンシは同等の Postgres JOIN よりも速く劣化します。
トランザクショナルデータの上にダッシュボード、フィルタ可能なリスト、分析レポートを重ねる B2B アプリでは、100 万レコード超の中央値レイテンシ勝負では Postgres がほぼ常に勝ちます。
実際のコスト構造
クラウドの価格ページは Postgres と MongoDB を似たように見せます。実際の保有コストはそうではありません。
Postgres はコモディティです。すべての主要クラウドがマネージドサービスを提供しており、チューニング方法を知っているエンジニアは豊富で、オープンソースの Postgres は本番でもラップトップでも同じように動きます。深夜 2 時に何かが壊れたとき、答えを見つけることができます。
マネージド MongoDB は便利ですが、専用クラスタ、バックアップ、VPC ピアリング、監査ログを備えたレベルに入るとプレミアム価格が設定されます。MongoDB の自己ホスティングは可能ですが、現在の市場では Postgres の運用スキルよりも希少で高価な運用スキルが必要です。
より大きなコストは二次コストです。年間で何エンジニアアワーがスキーママイグレーション、インデックスチューニング、消火活動に費やされるでしょうか。私たちが協業するチームは、これを日常的に 3 倍から 5 倍過小評価します。四半期あたり 2 エンジニアウィークを節約できるデータベースは、請求書上の表示価格に関係なく、何倍もの価値で元を取ります。
それぞれのエンジンが実際に勝つ場面
Postgres を選ぶべきは、データが本質的にリレーショナルである場合(顧客、注文、請求書、明細行)、強い一貫性と本物の参照整合性が必要な場合、チームが小さくデータベース専門家を雇えない場合、あるいは分析的な読み取りとダッシュボードが書き込みと同じシステムに存在する場合です。
MongoDB を選ぶべきは、ドキュメントが本当にネストされていて、めったに JOIN されない場合(製品カタログ、CMS コンテンツ、大量のイベントペイロード)、リージョンをまたぐ水平書き込みスケーリングが必要で結果整合性を受け入れられる場合、スキーマが急速に進化し、強制よりも柔軟性を重視する場合、あるいはそれをうまく運用する運用専門知識をすでに持っている場合です。
大半の B2B トランザクショナルアプリでは、率直な自己評価は Postgres に落ち着きます。それは MongoDB が間違っているという意味ではありません。デフォルトはチームの慣れではなく、ワークロードの形状によって獲得されなければならない、という意味です。
すでに本番稼働している場合の現実的な道筋
すでに誤ったエンジンで本番稼働しているのであれば、パニックで移行してはいけません。書き換えはデータベース問題を解決する最も高価な方法です。まず測定から始めてください。最も遅いクエリを 10 本プロファイリングし、抱えている運用オーバーヘッドの年間コストを算出し、最も負荷の高い 2〜3 のワークロードを対象にした部分的な移行の費用を、現状維持のコストと比較して見積もってください。
正しい答えがハイブリッドである場合もあります。現在のシステムを得意な領域で維持しつつ、もう一方のエンジンが本当に適合するワークロードにのみ Postgres または MongoDB を並行して導入するのです。これはフルの書き換えよりも小さく、テスト可能な賭けであり、プロダクト全体をコミットする前に前提を検証できます。
1 万レコード時点で選んだデータベースが、1000 万レコード時点でも正しいデータベースであることはめったにありません。痛みを伴う再プラットフォーム化を回避するチームは、火事ではなくスケジュールに沿ってこの選択を再検討するチームです。貴社のプロダクトがそのスケールに近づいており、次のスケーリング請求書が届く前にアーキテクチャに関する経験豊富な第二の意見を求めたいのであれば、MerkTechs のエンジニアリングチームは、貴社の CTO と着席し、実際のワークロードに対するトレードオフを検討することを喜んで行います。