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

午前2時、私はVercelのコンソールにある「Add Database」というオプションを見つめて、カーソルをPostgreSQL、MySQL、MongoDBの間で行き来させていました。プロジェクトのローンチまであと48時間だというのに、まだどのデータベースを使うべきか悩んでいたのです。ブラウザのタブは10個以上開かれていて、どれも技術記事ばかり。「Supabaseは無料枠が寛大」「PlanetScaleは爆速」「MongoDBこそがNext.jsに最適」…情報は錯綜していました。

正直、何を選べばいいのか分からなくなりました。

これは、これらのデータベースが使いにくいからではありません。選択肢が多すぎて、どれも素晴らしく見え、同時にどれも欠点があるように思えたからです。「もし間違った選択をしたら、後でコードを書き直すよりも大変な移行作業が待っているのではないか」という恐怖がありました。

もしあなたも同じように悩んでいるなら、この記事が助けになるはずです。PostgreSQL、MySQL、MongoDBという三大データベースの本質的な違いと、Vercel Postgres、Supabase、PlanetScale、MongoDB Atlasといったクラウドサービスをどう選ぶべきか、最も正直で分かりやすい言葉で解説します。

難しい専門用語を並べるのはやめましょう。

読み終えた後、たった3つの質問に答えるだけで、自信を持って決断できるようになります。

基礎を理解しよう——三大データベースの本質的な違い

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

よく「PostgreSQLとMySQLはリレーショナルデータベースで、MongoDBはNoSQLだ」と言われます。それは正しいですが、選定の役には立ちません。その分類だけでは、結局どれを選べばいいのか分からないからです。

それぞれの「性格」という観点から話しましょう。

PostgreSQL は、何でもできる万能なスイスアーミーナイフのような存在です。従来のリレーショナルデータだけでなく、JSON、全文検索、地理空間データも扱えますし、複雑なストアドプロシージャも書けます。思いつく限りの高度な機能はほぼ揃っています。しかし、それは学習コストが少し高いことも意味します。機能が多いので選択肢も多く、初心者は圧倒されるかもしれません。

性能面では、PostgreSQLは複雑なクエリに強いです。複数のテーブル結合（JOIN）を含むシナリオでは、同種のデータベースよりも30%ほど高速だというデータもあります。ただし代償として、適切に設定しないとリソース消費がMySQLより少し高くなる傾向があります。

MySQL は、安定して信頼できる「古き良き相棒」です。軽量で、枯れていて、ドキュメントは完備されており、コミュニティの情報量は圧倒的です。問題にぶつかっても、検索すればすぐに解決策が見つかります。多くの古いプロジェクトがMySQLを使っているのは、その「安心感」があるからです。

しかし、MySQLにも弱点はあります。基本的には垂直スケーリング（マシンの性能を上げること）に依存しており、MongoDBのようにサーバーを追加して横に広げる（水平スケーリング）のは簡単ではありません。小中規模のプロジェクトなら問題ありませんが、超高負荷なアプリを作る場合はボトルネックになる可能性があります。

MongoDB は全くの別物です。テーブルではなく、JSON形式のドキュメントを保存します。これは極めて高い柔軟性をもたらします。リレーショナルDBのように事前にテーブル構造を変更（ALTER TABLE）することなく、いつでもドキュメントに新しいフィールドを追加できます。仕様変更が激しいプロジェクトにとっては、まさに救世主です。

以前、CMS（コンテンツ管理システム）を作っていた時、記事のカスタムフィールドが頻繁に変更されました。「読了時間を追加して」「関連記事を出して」… MySQLだったらその都度マイグレーションが必要でしたが、MongoDBに変えてからはコードにフィールドを追加するだけで済みました。

しかし、MongoDBも万能ではありません。複雑な多対多の結合クエリ？苦手です（あるいは書くのが面倒です）。厳密なトランザクション整合性？サポートしていますが、リレーショナルDBほど自然ではありません。

つまり、データベース選びは「良いか悪いか」ではなく、「合うか合わないか」なのです。

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

では、どう判断すればいいのでしょうか。3つの実用的な軸を紹介します。

軸1: データのリレーション（関係性）はどれくらい複雑か

これが最も核心的な基準です。

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

逆に、データ構造が比較的フラットで、各データが独立的であれば、MongoDB が楽です。典型例はブログシステムの「記事とコメント」です。記事1つが1つのJSONドキュメントで、コメントはその中にネストさせるか、単純に関連付けるだけで済みます。この場合、MongoDBの柔軟性が強みになります。

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

プロダクトマネージャーが3日おきに仕様を変えてきますか？それなら MongoDB が命を救ってくれるでしょう。

最初はリレーショナルデータベースで完璧に設計しても、2週間後に「ユーザータグ機能追加」、その2週間後に「タグは複数選択可に」、さらに「タグに階層構造を」…となるのはよくある話です。そのたびにDBのマイグレーションスクリプトを書くのは苦行です。MongoDBなら、コード側で対応し、古いデータの互換性ロジックを入れるだけで済みます（もちろん、コード側でのデータ検証はより重要になりますが）。

逆に、会計ソフトやERPのように「ルールが明確でプロセスが固定されている」システムなら、リレーショナルデータベースの「制約（Constraint）」はむしろメリットです。DBレベルで不正なデータの書き込みを防げるので、コード側で心配事が減ります。

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

これを軽視してはいけません。

技術スタックに絶対的な優劣はありませんが、チームの習熟度の差は現実的な問題です。もしチーム全員がSQL育ちなら、無理にMongoDBを使うと、学習コストやハマりポイントの解決でプロジェクト期間が倍になるかもしれません。逆もまた然りです。

以前、JavaScript背景のメンバーばかりのスタートアップにいた時、最初はPostgreSQLを使っていましたが、複雑なクエリやインデックス最適化に苦戦しました。その後 MongoDB + Mongoose に切り替えたところ、開発効率が倍増しました。MongooseのAPIがJavaScriptのオブジェクト操作とほぼ同じ感覚で使えたからです。

もちろん、チームの「快適なゾーン」に固執すべきという意味ではありません。要件的にリレーショナルDBが必須なら学ぶべきです。しかし、どちらでも実装可能な要件なら、チームが慣れている方を選ぶのが正解です。

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

単なる価格比較ではないサービスの真実

データベースを決めても、次はクラウドサービスの落とし穴が待っています。どれも魅力的に見えますが、悪魔は細部に宿ります。

Vercel Postgres: ワンクリックデプロイの誘惑

もしプロジェクトをVercelにデプロイするなら、Vercel Postgres は最も手軽な選択肢です。数クリックでDBが用意され、環境変数が自動注入され、レイテンシも驚くほど低いです（ベンチマークでは頻繁に <10ms）。

しかし弱点も明白です。機能がシンプルすぎます。ユーザー認証システムも、ストレージサービスも、リアルタイム購読機能もありません。「純粋なPostgreSQLデータベース」だけが欲しいなら完璧ですが、「BaaS（Backend as a Service）」的な全機能を求めるなら、他のサービスを組み合わせる必要があります。

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

個人的に最も推しているのが Supabase です。なぜなら、単なるPostgreSQLデータベースではなく、ユーザー認証（Auth）、ファイルストレージ、リアルタイムデータ購読、そして使いやすい管理画面までセットになっているからです。

無料枠も太っ腹で、500MBのデータベース + 1GBのストレージがつきます。個人開発やMVP（実用最小限の製品）ならこれで十分お釣りが来ます。

性能面では PlanetScale に劣ります（QPSは5000程度 vs PlanetScaleの17000）が、中小規模のアプリなら体感差はほとんどありません。標準的なPostgreSQLなので、将来的な移行も容易です。

注意点として、トラフィックが急増した際に接続プールがボトルネックになることがありましたが、現在はSupabase Pooler（PgBouncerベース）が提供されており、設定さえすればServerless環境でも問題ありません。

PlanetScale: 性能の怪物だが代償あり

PlanetScale の性能は本物です。QPS（秒間クエリ数）は読み書き混合で約17,000、読み取り専用なら35,000に達するというベンチマークもあり、Supabaseの約3倍です。高負荷アプリなら、この差は決定的です。

また、「データベースブランチ」機能が超クールです。Gitのようにデータベースのブランチを作成し、そこでスキーマ変更をテストして、問題なければメインにマージする。チーム開発においてこれは神機能です。

しかし、大きな欠点が2つあります：

外部キー（Foreign Key）非対応：これは大きいです。データの整合性をアプリ層で担保する必要があります。
価格：2024年に無料プランが廃止され、月額$34からのスタートになりました。予算が限られる個人開発者には痛手です。

MongoDB Atlas: 柔軟性への対価は学習コスト

MongoDBの公式クラウドで、無料枠は512MB。Vercel Postgresより多く、Supabaseと同等です。

MongoDBを選ぶなら、Atlas一択でしょう。公式ならではの安定性と最新機能への対応は他に変えられません。

ただし、NoSQLの学習コストは計算に入れてください。SQLに慣れていると、集計パイプライン（Aggregation Pipeline）の書き方に戸惑うでしょう。また、トランザクション機能もありますが、リレーショナルDBほど直感的ではなく、パフォーマンスへの影響も考慮する必要があります。

隠れた罠として「帯域幅コスト」があります。Atlasはリクエスト数と転送量で課金されるため、頻繁なクエリや大量のデータ転送を行うと、DB料金より帯域料金が高くなることがあります。

性能比較表：

<10ms

Vercel Postgres レイテンシ

~5000

Supabase QPS

~17000

PlanetScale QPS

500MB+1GB

Supabase 無料枠

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

ここが一番重要です。多くの人がここで失敗します。

接続数制限：Serverlessの悪夢

Next.js をサーバーレス環境（Vercel等）で動かすと、リクエストごとに新しい関数インスタンスが立ち上がります。それぞれがDB接続を作ると、数百の同時アクセスであっという間にデータベースの接続数上限（Connection Limit）に達します。「Too many connections」…夜中にこのアラートで起こされるのは御免です。

解決策として、コネクションプール（Connection Pooling）が必須です。Supabase は Pooler を提供し、PlanetScale は最初からServerless対応の設計、Vercel Postgres も最適化されています。MongoDB Atlas の場合は自分でドライバの設定を調整する必要があります。

帯域幅料金：見えない請求

データベースとアプリ（Next.js）のリージョンが違うと、通信のたびにクロスリージョン転送量がかかります。MongoDB Atlasなど転送量課金のサービスでは、SELECT * のような無駄な全件取得をしていると、請求額が跳ね上がります。
対策：同じリージョンに配置する、必要なフィールドだけ取得する、キャッシュを活用する。

スケーリングコスト

PlanetScale や Supabase は従量課金や段階的なプランを持っています。Supabase の無料枠（500MB）を超えると、$25/月のProプランが必要です。PlanetScale は行数課金（読み取り/書き込み行数）なので、効率の悪いクエリを書いていると、アクセス数の割に高額な請求が来ることがあります。

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

技術的な詳細は十分でしょう。では、どう選ぶか？

質問1：あなたのプロジェクトタイプは？

これで8割決まります。

個人プロジェクト / MVP検証
- 予算はないが機能は欲しい → Supabase
- 無料枠が充実しており、AuthもStorageも全部入り。個人開発者の理想郷です。
- NoSQLが好き / データ構造が未定 → MongoDB Atlas
- 512MB無料で、スキーマ変更のストレスなし。
スタートアップ / 小規模チーム
- Vercelにデプロイしていて開発速度重視 → Vercel Postgres
- 設定ゼロの手軽さは、時間の節約になります。
- 認証やストレージも含めたバックエンド全体が欲しい → Supabase
- 開発工数を数週間分削減できます。
企業アプリ / 高負荷シナリオ
- 超高性能が必要 / 大規模チームでのスキーマ管理 → PlanetScale
- DBブランチ機能と圧倒的QPSは、月額$34以上の価値があります（ただし外部キー制約なしを受け入れる前提）。
コンテンツサイト / メディア
- 記事やコメントなど柔軟なデータ → MongoDB Atlas

質問2：予算と規模は？

予算ゼロ：Supabase か MongoDB Atlas の無料枠。Vercel Postgres も無料枠がありますが小さいです。PlanetScale は選択肢に入りません。
少額予算 (<$50/月)：Supabase Pro ($25) か Vercel Postgres ($20〜)。コスパならSupabase。
中規模予算 ($50-200)：PlanetScale ($34〜) が視野に入ります。
大規模：ここまで来たら自建（AWS RDS等）も検討に入りますが、運用コストを払って PlanetScale や Supabase Enterprise を使い続けるのも賢い選択です。

質問3：技術的負債への許容度（移行可能性）は？

「とりあえず動けばいい、将来の移行も辞さない」：無料の MongoDB Atlas や Supabase で爆速開発。成功したらその時考えればいいのです。
「堅実に作りたい、移行リスクを減らしたい」：PostgreSQL + Prisma という構成にしておきましょう。ORM（Prisma）を挟むことで、将来的にバックエンドのデータベースやクラウドサービスを乗り換える際のコード変更を最小限に抑えられます。PostgreSQL は標準的なので、どこへでも持っていけます。

私の個人的な推奨

今、新しいプロジェクトを始めるなら、私のデフォルト構成はこうです：

Next.js + Prisma + Supabase

理由：

Supabase の無料枠でスタートでき、スケールしてもProプランで対応可能。
Prisma の型安全性とマイグレーションツールが最高。
PostgreSQL なので、いざとなれば AWS や他のサービスへ逃げられる。
Auth や Storage が必要になったらすぐに有効化できる。

実践設定チェックリスト

最後に、各構成での重要ポイントをまとめます。

プラン1: Vercel Postgres + Prisma

Vercelの管理画面で Database 作成。
.env に自動注入される POSTGRES_PRISMA_URL を使用。
npx prisma generate でクライアント生成。
注意：Prisma Client のインスタンス化時にグローバル変数へのキャッシュを行い、HMR（ホットリロード）での接続数枯渇を防ぐこと。

プラン2: Supabase + Prisma

Supabase でプロジェクト作成後、Connection Pooling (Transaction mode) の URL を取得。
環境変数の DATABASE_URL に設定。
Migration 用には DIRECT_URL (Session mode) を設定。
注意：Row Level Security (RLS) を適切に設定しないとデータが丸見えになるリスクあり（Prisma経由ならService Roleキーを使うのでRLSバイパスも可能だが、クライアントから直接呼ぶなら必須）。

プラン3: MongoDB Atlas + Mongoose

接続文字列の <password> を忘れず置換。
serverSelectionTimeoutMS を設定し、Lambdaのコールドスタート対策。
.lean() を使ってクエリ結果を軽量なJSオブジェクトにする。
注意：インデックスは手動で貼る必要があります。貼らないと検索が激重になります。

共通の鉄則

環境変数：.env.local と .env.production を使い分け、絶対にGitにコミットしない。
接続プール：Serverless環境では命綱。必ず設定を確認する。
エラー処理：DBダウン時やタイムアウト時の try-catch を忘れない。
監視：接続数やクエリ速度のモニタリングを怠らない。

データベース選びに正解はありませんが、「致命的な間違い」はあります。この記事のフレームワークを使って、あなたのプロジェクトに最適な選択をしてください。そして、悩みすぎる前に手を動かし始めましょう！

FAQ

Next.js プロジェクトで PostgreSQL と MongoDB どちらを選ぶべき？

データのリレーション（関係性）の複雑さで決めましょう。ECサイトのように多対多の複雑な結合が必要なら PostgreSQL が最適です。ブログやログ管理のようにデータ構造が柔軟で頻繁に変更されるなら MongoDB が適しています。迷ったら、エコシステムが成熟している PostgreSQL を推奨します。

Supabase と Vercel Postgres どっちが良い？

Vercel にデプロイして純粋な DB だけが欲しいなら、統合がスムーズな Vercel Postgres。ユーザー認証、ファイルストレージ、リアルタイム機能などバックエンド全般の機能が必要なら Supabase が圧倒的に便利で、無料枠も大きいです。

PlanetScale は月額 $34 の価値がある？

性能要件によります。高負荷（QPS 5000以上）なアプリや、チーム開発でデータベースのブランチ機能を使いたいなら価値があります。個人開発や小規模なら、まずは無料または安価な Supabase から始めるのが賢明です。

Serverless 環境での「Too many connections」エラーの対策は？

コネクションプール（Connection Pooling）が必須です。Supabase は Pooler モードを有効化、PlanetScale はネイティブ対応、Vercel Postgres も最適化済みです。MongoDB の場合は接続プール設定を適切に行うか、Serverless インスタンス内でクライアントをキャッシュする実装が必要です。

将来的にデータベースを移行するのは大変？

Prisma や Drizzle などの ORM を使って抽象化しておけば、コードの書き直しは最小限で済みます。PostgreSQL は標準的なので、Supabase から AWS RDS への移行などは容易です。一方、MongoDB からリレーショナルDBへの移行は、設計の根本が変わるため非常に困難です。

8 min read · 公開日: 2026年1月5日 · 更新日: 2026年1月22日