Next.js データベース選定ガイド：PostgreSQL、MySQL、MongoDB とクラウドサービスの完全比較

ローンチまで 48 時間。Vercel コンソールの「Add Database」を前に、カーソルが Postgres、MySQL、MongoDB の間を行き来しています。ブラウザには 10 タブの技術記事——「Supabase は無料枠が太い」「PlanetScale は性能最強」「MongoDB が Next.js に最適」と、それぞれ別の結論ばかり。

選択肢が多すぎる。どれも良さそうで、どれにも限界がある。しかも一度選びを誤ると、後からの移行コストはコードの書き直し以上に跳ね上がる。

同じ悩みをしているなら、この記事はそのためのものです。PostgreSQL、MySQL、MongoDB の本質的な違いと、Vercel Postgres、Supabase、PlanetScale、MongoDB Atlas の選び方を、できるだけ分かりやすく整理します。

虚論は省きます。

読み終えたら、3 つの質問に答えるだけで、かなり早く決められます。

まず基礎——三大 DB の本質的な違い

PostgreSQL vs MySQL vs MongoDB：リレーショナルか否かだけではない

よく「PostgreSQL と MySQL はリレーショナル、MongoDB は NoSQL」と言われます。正しいですが、選定にはあまり役立ちません——結局どれを選べばいいか分からないからです。

別の角度から、それぞれの「性格」を見てみましょう。

PostgreSQL は、機能が揃ったスイスアーミーナイフのような存在です。従来のリレーショナルデータに加え、JSON、全文検索、地理空間データ、複雑なストアドプロシージャまで扱えます。高度な機能はほぼ揃っています。その分、学習曲線はやや急——選択肢が多く、初心者は迷いやすい。

性能面では、複雑なクエリに強いです。多テーブル JOIN のシナリオでは、同種 DB より約 30% 速いというテスト結果もあります。ただし設定を誤ると、MySQL よりリソース消費が高くなることもあります。

MySQL は、安定した古参の相棒です。軽量で成熟し、ドキュメントも豊富。コミュニティの知見は膨大で、問題は検索すれば大抵解決します。多くの既存プロジェクトが MySQL を選ぶのは、手離れの良さがあるからです。

弱点もあります。基本は垂直スケール——マシン性能の上限に達したら、より強いマシンに載せ替えるしかなく、MongoDB のようにサーバーを横に増やすのは簡単ではありません。中規模以下なら問題になりにくいですが、超高並行アプリではボトルネックになり得ます。

MongoDB はまったく別物です。テーブルではなく JSON 形式のドキュメントを保存します。柔軟性が非常に高く、あるドキュメントにフィールドを足すのも、RDB の ALTER TABLE のようにスキーマ変更を伴いません。要件変更が激しいプロジェクトでは、かなり助かります。

以前、CMS を作っていたとき、記事のカスタムフィールドが頻繁に変わりました。「読了時間を追加」「関連記事を出す」——MySQL なら都度 ALTER TABLE と履歴データの互換性を考える必要がありました。MongoDB に替えてからは、コード側でフィールドを足すだけで済みました。

ただし MongoDB も銀の弾丸ではありません。複雑な多テーブル結合は苦手、あるいは書きにくい。トランザクションはサポートしますが、RDB ほど自然ではありません。

つまり DB 選びは「良い/悪い」ではなく、「合う/合わない」です。

いつどれを使う？ 3 つの判断軸

絶対的な「最強」はない。ではどう判断するか——実用的な 3 軸を紹介します。

軸 1：データの関係性はどれくらい複雑か

これが最も重要です。

「A が B に関連し、B が C に関連する」ロジックが大量にありますか？ EC サイトの例：ユーザー、注文、商品、カテゴリ、タグ……多層ネストで JOIN が頻繁なら、PostgreSQL か MySQL が第一候補です。RDB はこの用途のために設計されており、外部キー制約やトランザクション整合性が最初から備わっています。

逆にデータ構造がフラットで、各レコードが比較的独立しているなら MongoDB が楽です。典型例はブログの記事とコメント。記事 1 件が 1 つの JSON ドキュメントになり、コメントはネストするか、単純に関連付けるだけで済みます。

軸 2：要件変更はどれくらい頻繁か

プロダクトマネージャーが三日おきに仕様を変えるなら、MongoDB が助けになることがあります。

RDB で完璧に設計しても、2 週間後に「ユーザータグ機能」、さらに「複数選択」、さらに「階層構造」——毎回 DB とマイグレーションスクリプトを直すのは消耗戦です。MongoDB ならコードでフィールドを足し、旧データ互換はアプリ側で処理できます（その代わり、DB 層での検証はコード側の責任が増えます）。

一方、会計ソフトや ERP のようにルールが固定されたシステムなら、RDB の制約はむしろメリット。DB レベルで不正データを防げ、コード側の心配が減ります。

軸 3：チームは何に慣れているか

これを軽視しないでください。

技術に絶対的な優劣はありませんが、チームの習熟度差は現実的なコストです。SQL 出身のチームが無理に MongoDB を使うと、学習とハマりどころ解消にプロジェクト期間以上の時間を使うことも。逆も同様です。

以前、JavaScript 背景ばかりのスタートアップでは PostgreSQL で複雑クエリやインデックス最適化に苦戦しました。MongoDB + Mongoose に替えると開発速度が倍近く上がりました。Mongoose の API が JS オブジェクト操作に近く、思考の切り替えが少ないからです。

もちろん、要件上 RDB が必須なら学ぶべきです。どちらでも実装できるなら、チームが慣れた方を選ぶのが正解です。

クラウドサービス大混戦——Vercel Postgres、Supabase、PlanetScale、MongoDB Atlas の選び方

クラウド比較：価格だけでは決まらない

DB を決めても、次はクラウドサービスの落とし穴です。

Vercel Postgres、Supabase、PlanetScale、MongoDB Atlas——どれも魅力的ですが、悪魔は細部に宿ります。順に見ていきましょう。

Vercel Postgres：ワンクリックの誘惑

Vercel にデプロイしているなら、ほぼ最も手離れが良い選択肢です。数クリックで DB ができ、環境変数も自動注入。レイテンシは驚くほど低く、ベンチマークではしばしば <10ms です。

弱点は機能のシンプルさ。組み込み認証もストレージもリアルタイム購読もありません。「PostgreSQL だけ欲しい」なら完璧。「バックエンド一式」が欲しいなら別サービスを足す必要があります。

料金は無料版 256MB。有料は $20/月〜。Vercel との深い統合を考えると、時間の節約としては妥当な投資です。

Supabase：オープンソース界のオールラウンダー

個人的に好きな選択肢の一つです。PostgreSQL に加え、認証、ファイルストレージ、リアルタイム購読、管理 UI（Supabase Studio）まで揃っています。

無料枠も太い：DB 500MB + ストレージ 1GB。個人開発や MVP には十分。独立開発者が Supabase 無料版だけでプロダクトを回している例も多いです。

性能は PlanetScale に劣ります。ベンチマークでは QPS 約 5000、PlanetScale は約 17000。ただし中小規模アプリでは体感差は小さいことが多い。標準 PostgreSQL なので移行もしやすいです。

注意点：トラフィック急増時に接続プールがボトルネックになることがあります。Pooler 機能で Serverless の接続数問題に対応できます。設定すれば OK です。

PlanetScale：性能モンスター、だが代償あり

性能は本物です。混合読み書きで QPS ~17000、読み取り専用 ~35000——Supabase の約 3 倍。高並行アプリでは差がはっきり出ます。

DB ブランチも強力です。Git のように schema 変更をブランチで試し、問題なければ本流にマージ。チーム開発ではかなり便利です。

ただしハードルも 2 つ：

第一、外部キー非対応。外部キー前提の設計なら、アプリ層で整合性を担保する必要があります。

第二、高い。2024 年に無料プランが廃止され、$34/月〜。予算が厳しい個人・スタートアップには重いです。

超高並行や大規模チームの schema 管理が必要なら投資の価値あり。そうでなければ、コスパの良い選択肢も残っています。

MongoDB Atlas：柔軟性の代償は学習コスト

MongoDB 公式クラウド。無料版 512MB——Vercel Postgres の 2 倍、Supabase と同程度。デプロイも簡単で、多リージョン対応です。

MongoDB を選ぶなら Atlas が自然な選択。公式ならではの安定性と機能更新があります。

NoSQL の学習コストは見落としがちです。SQL 出身だと Aggregation Pipeline に慣れが必要。トランザクションも RDB ほど自然ではなく、シーンによっては性能も落ちます。

隠れた罠は帯域料金。ストレージとリクエスト量で課金するため、クエリが多いと DB 本体より転送料が膨らむことがあります。知り合いが Atlas で帯域が請求の 60% を占め、クエリ最適化とキャッシュでようやく抑えた、という話も聞きました。

性能比較表：

隠れたコスト：月額だけ見てはいけない

ここが特に重要です。多くの人がここでつまずきます。

請求書の DB 月額は氷山の一角。本当に痛いのは、見えにくい費用です。

接続数制限：Serverless の悪夢

Next.js を Vercel など Serverless に載せると、リクエストごとに関数インスタンスが立ち上がります。各インスタンスが DB 接続を張ると、数百同時アクセスで接続プールが枯渇します。

従来型の接続プール設計は Serverless では効きにくい。「Too many connections」「Connection pool exhausted」——深夜 3 時のアラートは二度と経験したくない、という人も多いはずです。

幸い、主要クラウドは対策を用意しています。Supabase は Pooler、PlanetScale は接続プール標準、Vercel Postgres は自社統合で最適化。MongoDB Atlas は自前で接続プールライブラリを入れるか、接続数アラートと付き合う必要があります。

帯域料金：クエリ多発の見えない killer

DB とアプリが別リージョンだと、クエリのたびにクロスリージョン転送が発生し、帯域料が跳ね上がります。

MongoDB Atlas では特に顕著。リクエスト数と転送量課金のため、返却データが大きいと DB 本体より転送が高くなることも。

対策：

1. DB とアプリは可能な限り同一リージョン
2. 必要なカラムだけ返す。SELECT * は避ける
3. キャッシュで重複クエリを減らす

スケールコスト：長期投資として見る

PlanetScale も Supabase も、ストレージと接続数で段階課金です。最初は無料や低価格帯でも、データが増えるとプランが跳ね上がります。

例：Supabase 無料 500MB を超えると Pro $25/月（8GB 含む）。10GB まで伸びると追加料金。計画なしに月額が倍になると、かなりショックです。

PlanetScale は行数課金。$34/月で 100 億行読み取り + 5000 万行書き込み。超過分は従量。書き込みが多いアプリほどコストが伸びやすいです。

移行コスト：選びを誤ったあとの代償

最も見落とされがちなコストです。

DB 移行はデータのコピーだけではありません。schema 変換、コード適合、テスト——小プロジェクトなら 1〜2 日、大規模だと数ヶ月もあり得ます。

あるプロジェクトでは最初 MongoDB で始め、複雑クエリに苦しんで PostgreSQL へ移行。新 schema 設計に 1 週間、移行スクリプト調整に 2 週間、検証環境と本番の切り替えを含め、ほぼ 2 ヶ月かかりました。

だから今は、迷ったら主流で移行しやすい構成を優先します。Prisma や Drizzle で抽象化しておけば、将来 DB を替えるときのコード変更は抑えられます。

決断フレームワーク——3 つの質問で決める

質問 1：プロジェクトタイプは？

技術詳細は十分。実務では「結局どれ？」に戻りましょう。

複雑な性能数値を覚えなくても、3 つの質問でかなり絞れます。

最初の質問：プロジェクトタイプは？

ここで 8 割決まります。

個人プロジェクト / MVP 検証

予算は限られるが機能は欲しい → Supabase

無料 500MB + 1GB ストレージ、認証とリアルタイム購読付き。個人開発者には理想的。Supabase 無料版だけで SaaS を数千ユーザー規模まで回している例も多いです。

NoSQL に慣れている、または schema が流動的 → MongoDB Atlas

512MB 無料。CMS、ブログ、ログ収集など schema 固定が難しい用途向き。

スタートアップ / 小規模チーム

すでに Vercel デプロイで開発速度重視 → Vercel Postgres

無料 256MB は小さいものの、環境変数自動注入やエッジ連携で設定時間を削れます。スタートアップで最も高いのは時間で、$20/月は払う価値があることも多いです。

認証・ストレージなどバックエンド一式 → Supabase

DB だけでなくバックエンド全体。Authentication、Storage、Edge Functions が揃い、数週間分の開発を節約できます。

企業アプリ / 高並行

ユーザー数が多く性能要件が厳しい → PlanetScale

QPS ~17000 は冗談ではなく、DB ブランチは大チームに効きます。$34/月〜は収益のある企業なら許容範囲のことも。

ただし外部キー非対応。外部キー前提の業務ロジックなら再検討が必要です。

コンテンツサイト / ブログ / メディア

データ構造が柔軟でクエリは比較的シンプル → MongoDB Atlas

記事、コメント、タグはドキュメント DB と相性が良い。全文検索も RDB より扱いやすい場面があります。

リアルタイムコメント・通知 → Supabase

Realtime は PostgreSQL の Change Data Capture ベース。設定すれば WebSocket を自前構築せず購読できます。

質問 2：予算と規模は？

お金の話も避けられません。

ゼロ予算（完全無料）

Supabase（500MB + 1GB）か MongoDB Atlas（512MB）が現実的な選択肢。

Vercel Postgres も無料版あり（256MB）ですが、伸びしろは小さい。PlanetScale は無料版なし——除外。

認証やファイルアップロードがありそうなら Supabase 優先。純粋なデータ保存なら MongoDB Atlas も柔軟です。

小予算（月 <$50）

Supabase Pro（$25/月）か Vercel Postgres（$20/月〜）が範囲内。

Supabase Pro は DB 8GB + ストレージ 100GB + Auth 5 万 MAU。コスパは高い。アプリ全体が Vercel なら、Vercel Postgres の統合で省ける運用工数も価値があります。

MongoDB Atlas は従量で小規模なら月数ドルもあり得ます。帯域料だけ監視してください。

中予算（月 $50〜200）

PlanetScale（$34/月〜）、Supabase Team（$599/年、約 $50/月）も視野に。

QPS 要件が高くなければ Supabase Team の方がコスパ良し。超高並行なら PlanetScale の性能投資を検討。

大規模 / 高並行

この段階ではクラウドのコスパが下がり、AWS RDS、Google Cloud SQL、自前 PostgreSQL クラスタを選ぶ会社も増えます。

DBA がいない小チームなら、PlanetScale や Supabase Enterprise に運用を任せ、プロダクトに集中するのも合理的です。

質問 3：技術的負債への許容度は？

最後の質問。見落とされがちですが重要です。

後から移行するリスクを受け入れられる

まず無料で検証し、伸びが見えたらアップグレードや移行——成功プロダクトの典型パターンです。MongoDB Atlas 無料 → 複雑クエリで PostgreSQL へ → トラフィック急増で自前クラスタ、という流れも珍しくありません。

準備しておくこと：

1. Prisma/Drizzle で抽象化し、移行コストを下げる
2. DB アクセスを集中管理し、ファイルに散らさない
3. 定期バックアップ——移行時の保険

一度で済ませ、後の手戻りを減らしたい

成熟した主流構成：PostgreSQL + Supabase か PostgreSQL + 自前。

PostgreSQL は最も成熟した OSS DB の一つ。今日 Supabase、明日 AWS RDS や自前サーバーへ——SQL はほぼそのまま移せます。

MongoDB は柔軟ですがエコシステムが閉じがち。RDB へ替えるなら、ほぼ作り直しに近いです。

個人的なデフォルト

新規プロジェクトの既定は Next.js + Prisma + Supabase です。

理由：

• Supabase 無料枠で始め、成長したら Pro へ
• Prisma の型安全とマイグレーションで安心
• PostgreSQL エコシステムで、いつでも別クラウドへ移せる
• Auth や Storage が必要になったらそのまま使える

高並行や、DB 運用に慣れたチームなら PlanetScale や自前構成も選択肢です。

実践設定チェックリスト

クイックスタートの要点

理論はここまで。実務のポイントだけ。

よくある組み合わせの設定要点です。長大なコードは省き、押さえる場所を示します。

構成 1：Vercel Postgres + Prisma

最短 5 分程度で動かせます。

手順：

1. Vercel プロジェクトで「Storage」→「Create Database」→ Postgres
2. 環境変数は .env に自動注入。process.env.POSTGRES_PRISMA_URL を使用
3. npx prisma generate でクライアント生成
4. Prisma の接続プール設定を忘れない——Serverless では接続数が爆発しやすい

注意：

• 開発 DB と本番 DB は分離。本番データを誤削除しない
• Prisma migration は git にコミット。チームでズレないように

構成 2：Supabase + Prisma

Auth も必要なら最もバランスが良い構成の一つ。

手順：

1. Supabase でプロジェクト作成、接続文字列取得
2. 環境変数に DATABASE_URL と DIRECT_URL（migration 用）を設定
3. Supabase Pooler を有効化し、接続数問題を回避
4. Auth が必要なら @supabase/auth-helpers-nextjs で Next.js と統合

注意：

• Row Level Security（RLS）を適切に設定。設定ミスはデータ漏洩につながる
• Realtime はデフォルト OFF。テーブル設定で有効化が必要

構成 3：MongoDB Atlas + Mongoose

JavaScript チーム向け。

手順：

1. Atlas でクラスタ作成。接続文字列の <password> を実パスワードに置換
2. Mongoose で Schema 定義——schemaless でもコード側の型制約は必要
3. 接続時に serverSelectionTimeoutMS を設定し、コールドスタートタイムアウトを回避
4. .lean() でプレーン JS オブジェクトを返すと性能が良い

注意：

• 接続文字列（パスワード含む）を git にコミットしない。.env.local + .gitignore
• インデックスは手動作成。無いとクエリが極端に遅い
• Aggregation は学習コストあり。事前にドキュメントを読む

共通の鉄則

どの構成でも：

1. 環境変数：.env.local（ローカル）と本番用を分け、混ぜない
2. 接続プール：Serverless では必須
3. エラー処理：DB クエリは try-catch。生エラーをユーザーに見せない
4. バックアップ：クラウドでも障害は起きる
5. 監視：接続数、クエリ時間をアラート設定

結論

ここまで読んで、最初の問いに戻りましょう。Next.js プロジェクトの DB は何を選ぶ？

標準答案はありません。ただし決断フレームワークはあります。

3 つの質問：

1. プロジェクトタイプ：個人？スタートアップ？企業？
2. 予算規模：ゼロ？小予算（<$50）？中〜大？
3. 技術的負債：後から移行 OK？ それとも堅実に一発？

まだ迷うなら、保守的な提案：Supabase + Prisma + PostgreSQL。

理由：

• 無料枠で個人プロジェクトを収益化まで持たせやすい
• Database + Auth + Storage で開発時間を節約
• PostgreSQL エコシステムで移行先が多い
• Prisma の型安全でコード品質を保てる

極限性能（PlanetScale）、柔軟 schema（MongoDB Atlas）、Vercel 深統合（Vercel Postgres）など特殊要件があれば、そちらを優先してください。

最後に——DB 選定は一度きりの決定ではなく、進化するプロセスです。まず出して検証し、必要に応じて最適化。技術選定でローンチを遅らせないでください。

今すぐプロジェクトを開き、3 つの質問に 10 分で答え、コードを書き始めましょう。

困ったら、コメント欄で。