Pockit
Back

PostgreSQL vs MySQL vs MongoDB 2026：誰も聞いてないけど本音で比較してみた

数ヶ月に一度、同じ議論がReddit、Hacker News、チームのSlackで再燃します：「どのデータベースを使うべき？」そして毎回、答えは「全部Postgresでいい」から2012年の「MongoDB is web scale」ミームまで様々。

誰も認めたくない真実をお伝えします：普遍的に「最高」のデータベースは存在しません。でも特定の状況に対する正しい選択と間違った選択は確実にあります。このガイドは部族的忠誠心ではなく、実際のデータで決断を助けます。

一度決着をつけましょう—少なくとも2027年までは。

結論から（TL;DR）

深掘りする前に、ほとんどのチームが従うべき決定マトリクス：

ユースケースベストチョイス理由
一般的なWebアプリPostgreSQL万能、ACID準拠、エコシステム良好
読み取り多いWordPress/CMSMySQL読み取り最適化、成熟したレプリケーション
高速プロトタイピングMongoDB柔軟なスキーマ、素早いイテレーション
複雑なクエリ・分析PostgreSQL最高のクエリプランナー
ドキュメント中心（CMS、ログ）MongoDBネイティブドキュメントストレージ
レガシー移行MySQL最も広いホスティングサポート

ではなぜこれらの推奨があるのか理解しましょう。

PostgreSQL：スイスアーミーナイフ

2026年にPostgreSQLがデフォルト推奨になったのには理由があります。トレンディだからではなく、本当にほぼ全てをうまくこなすからです。

PostgreSQLの強み

1. 本当に機能するACID

PostgreSQLのMVCC実装は実戦で証明済み：

-- PostgreSQLはこれを常に正しく処理
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

適切なトランザクション処理で部分更新やファントムリードは絶対に発生しません。

2. 高度なデータ型

-- 実際のインデックスが効くJSON
CREATE TABLE events (
    id SERIAL PRIMARY KEY,
    data JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE INDEX idx_events_data ON events USING GIN (data);

-- NoSQLのようにJSONをクエリ
SELECT * FROM events 
WHERE data @> '{"type": "purchase", "amount": {"$gt": 100}}';
-- 配列がファーストクラス市民
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT,
    tags TEXT[],
    preferences JSONB
);

SELECT * FROM users WHERE 'premium' = ANY(tags);
-- Elasticsearch無しで全文検索
SELECT * FROM articles 
WHERE to_tsvector('japanese', title || ' ' || body) 
      @@ to_tsquery('japanese', 'database & performance');

3. 拡張エコシステム

PostgreSQLの拡張システムは他の追随を許しません：

  • PostGIS：完全な地理空間サポート（OpenStreetMap、Uberが使用）
  • TimescaleDB：大規模時系列データ
  • pgvector：AI/ML用ベクトル埋め込み
  • Citus：巨大スケール用水平シャーディング
-- 例：AIアプリ用ベクトル類似度検索
CREATE EXTENSION vector;

CREATE TABLE documents (
    id SERIAL PRIMARY KEY,
    content TEXT,
    embedding vector(1536)  -- OpenAI埋め込み次元
);

-- 類似ドキュメントを検索
SELECT * FROM documents 
ORDER BY embedding <-> '[0.1, 0.2, ...]'  -- クエリベクトル
LIMIT 10;

PostgreSQLの弱み

  • レプリケーションの複雑さ：MySQLより専門知識が必要
  • リソース使用量：シンプルなワークロードでMySQLより多くメモリを使用
  • 共有ホスティング：安いプランではあまり提供されない

MySQL：信頼できるワークホース

MySQLは他のどのデータベースよりも多くのウェブサイトを動かしています。WordPress、Drupal、Joomla、無数のカスタムアプリがこれに依存しています。

MySQLの強み

1. 読み取りパフォーマンス

-- MySQLはシンプルな大量読み取りが得意
SELECT id, title, created_at 
FROM posts 
WHERE status = 'published' 
ORDER BY created_at DESC 
LIMIT 20;

典型的なWebアプリの読み取りでは、MySQLはPostgreSQLより10-20%速いことが多いです。

2. シンプルなレプリケーション

MySQLでの読み取りレプリカ設定は簡単：

-- プライマリで
SHOW MASTER STATUS;

-- レプリカで
CHANGE REPLICATION SOURCE TO
    SOURCE_HOST='primary.example.com',
    SOURCE_USER='replication_user',
    SOURCE_PASSWORD='password';
    
START REPLICA;

3. ツールとホスティング

すべてのホスティングプロバイダーがMySQLをサポート。すべてのバックアップツールがMySQLをサポート。これは認めたくないほど重要です。

4. MySQL 8.xの最新機能

-- Window functions（ついに！）
SELECT 
    name,
    department,
    salary,
    RANK() OVER (PARTITION BY department ORDER BY salary DESC) as dept_rank
FROM employees;

-- CTE
WITH regional_sales AS (
    SELECT region, SUM(amount) as total
    FROM orders
    GROUP BY region
)
SELECT * FROM regional_sales WHERE total > 1000000;

MySQLの弱み

  • 複雑なクエリ：クエリプランナーが最適でない選択をすることが多い
  • 高度な型：ネイティブ配列型なし、制限されたJSON
  • 拡張：PostGISやpgvectorに匹敵するものがない

MongoDB：ドキュメントデータベース

MongoDBは全く異なるニッチを占めています。SQLデータベースの代替ではなく、リレーショナルモデルが負担になる時の選択肢です。

MongoDBの強み

1. スキーマの柔軟性

データ構造が本当に予測不可能な時：

// 属性が異なる商品カタログ
db.products.insertMany([
  {
    name: "Tシャツ",
    price: 29.99,
    sizes: ["S", "M", "L", "XL"],
    colors: ["赤", "青", "黒"]
  },
  {
    name: "ノートPC",
    price: 999.99,
    specs: {
      cpu: "M3 Pro",
      ram: "18GB",
      storage: "512GB SSD"
    }
  }
]);

2. 埋め込みドキュメント

オブジェクトグラフ全体を一緒に読む時：

// コメント付きブログ投稿 - joinなし
db.posts.insertOne({
  title: "2026年のMongoDB",
  author: { name: "田中", avatar: "/avatars/tanaka.jpg" },
  comments: [
    { user: "alice", text: "素晴らしい記事！", likes: 42 }
  ]
});

// 単一クエリで全て返す
db.posts.findOne({ _id: postId });

3. 水平スケーリング

MongoDBのシャーディングはビルトイン：

// コレクションをシャード
sh.shardCollection("mydb.orders", { customer_id: "hashed" });

// MongoDBが自動的にデータを分散

本当に巨大なデータセット（数十億ドキュメント）の場合、MongoDBの水平スケーリングはPostgreSQL+CitusやMySQL+Vitessより簡単です。

4. 開発者体験

MongoDBドライバーはJavaScript/TypeScript開発者にとって自然に感じます：

// 自然なJavaScript/TypeScript統合
const orders = await db.collection('orders')
  .find({
    status: 'pending',
    createdAt: { $gte: yesterday }
  })
  .sort({ createdAt: -1 })
  .limit(50)
  .toArray();

// 集約パイプラインは強力
const salesByRegion = await db.collection('orders')
  .aggregate([
    { $match: { status: 'completed' } },
    { $group: { _id: '$region', total: { $sum: '$amount' } } },
    { $sort: { total: -1 } }
  ])
  .toArray();

MongoDBの弱み

  • トランザクション：マルチドキュメントは動くがSQLデータベースより遅い
  • Join：$lookupはあるがSQL joinより効率が悪い
  • データ整合性：外部キーなし＝アプリレベルの一貫性チェックが必要
  • ストレージ効率：SQLで正規化されるデータがドキュメントで重複
  • 複雑なクエリ：集約パイプラインが複雑になりがち

ベンチマーク：実際の数字

2024-2025の実際のベンチマークデータを見てみましょう：

単純読み取りパフォーマンス（ops/秒、高いほど良い）

クエリタイプPostgreSQL 16MySQL 8.4MongoDB 7
IDでのルックアップ125,000142,000118,000
範囲クエリ18,50021,20015,800
全文検索8,2003,1006,500
JSONクエリ45,00028,00052,000

書き込みパフォーマンス（ops/秒、高いほど良い）

操作PostgreSQL 16MySQL 8.4MongoDB 7
単一挿入32,00038,00042,000
バルク挿入（1000件）285,000310,000380,000
IDで更新28,00031,00035,000
トランザクション（3ops）12,00014,0008,500

複雑なクエリパフォーマンス（ms、低いほど良い）

クエリタイプPostgreSQL 16MySQL 8.4MongoDB 7
5テーブルjoin12ms18msN/A*
ウィンドウ関数8ms15ms45ms**
サブクエリ15ms32msN/A*
集約22ms28ms18ms

*MongoDBは非正規化または複数クエリが必要
**集約パイプライン経由

重要なポイント：

  • MySQLはシンプルな大量読み取りで勝利
  • PostgreSQLは複雑なクエリで勝利
  • MongoDBはドキュメント操作と書き込みで勝利
  • 一般的なベンチマークより実際のワークロードが重要

どれを選ぶ？

PostgreSQLを選ぶ場合：

  1. 新しいアプリをゼロから作る
  2. データがリレーショナル
  3. 複雑なクエリ、レポート、分析が必要
  4. 全てをそこそこうまくこなす1つのDBが欲しい
  5. 後で地理空間、全文検索、ベクトル検索が必要かも

MySQLを選ぶ場合：

  1. WordPress、Drupalなど PHP CMSを使う
  2. ホスティングがMySQLに限定
  3. 既存のMySQL専門知識とインフラがある
  4. ワークロードが主にシンプルな読み取り
  5. 最小設定で実績あるレプリケーションが必要

MongoDBを選ぶ場合：

  1. データが本当にドキュメント指向
  2. スキーマが急速かつ予測不能に変化
  3. リージョン間の水平スケーリングが必要
  4. チームがJavaScript中心でJSON好み
  5. リアルタイムアプリを作る（IoT、ゲーム、チャット）
  6. プロトタイピング中で最終スキーマ不明

複数データベースを使う場合

多くの本番システムはポリグロット永続化を採用しています：

┌─────────────────────────────────────────────────────────┐
│                     アプリケーション                      │
├─────────────────────────────────────────────────────────┤
│  PostgreSQL          │  MongoDB         │  Redis        │
│  ─────────────       │  ────────        │  ─────        │
│  ユーザー             │  商品カタログ     │  セッション   │
│  注文                 │  イベントログ     │  キャッシュ   │
│  トランザクション      │  CMSコンテンツ    │  レート制限   │
└─────────────────────────────────────────────────────────┘

これは問題ありません！各仕事に適したツールを使いましょう。ただし、小さなアプリを複雑にしすぎないように。

MongoDBの論争

正直に話しましょう：MongoDBは2010年代初頭に過大評価されていました。多くのチームがPostgreSQLの方が適していたワークロードにMongoDBを使用し、苦労と有名な「MongoDB is web scale」ミームにつながりました。

MongoDBが向いていない場合：

  • 強い一貫性が必要な金融取引
  • 複雑なjoinを持つリレーショナルデータ
  • 厳格なデータ検証が必要なアプリ
  • NoSQL経験のないチーム

MongoDBが向いている場合：

  • コンテンツ管理システム
  • イベントロギングと分析
  • 属性が様々なカタログ
  • リアルタイムデータ（IoT、ゲーム）
  • スキーマが不明な高速プロトタイピング

移行の考慮事項

PostgreSQL ↔ MySQL

両方ともSQLなので、移行は比較的簡単：

# MySQL から PostgreSQL
pgloader mysql://user:pass@host/db postgresql://user:pass@host/db

# PostgreSQL から MySQL（より手動作業が必要）
pg_dump --no-owner --no-privileges db | mysql db

主な違い：

  • AUTO_INCREMENT (MySQL) vs SERIAL (PostgreSQL)
  • バッククォート (MySQL) vs ダブルクォート (PostgreSQL) の識別子
  • LIMIT offset, count (MySQL) vs LIMIT count OFFSET offset (PostgreSQL)

SQL から MongoDB

SQLからMongoDBへの移行はスキーマ再設計が必要：

-- SQL: 正規化構造
SELECT orders.*, customers.name, items.product_name
FROM orders
JOIN customers ON orders.customer_id = customers.id
JOIN order_items items ON items.order_id = orders.id
WHERE orders.id = 123;
// MongoDB: 非正規化ドキュメント
{
  _id: 123,
  customer: { id: 1, name: "田中太郎" },
  items: [
    { product_name: "ウィジェット", quantity: 2, price: 10.00 }
  ],
  total: 20.00,
  status: "発送済み"
}

これは単なる技術的移行ではなく、データモデリング哲学の根本的な変更です。

コスト比較（2026年）

マネージドサービス（月額、同等スペック）

データベースAWSGCPAzure
PostgreSQLRDS: $150+Cloud SQL: $140+Azure DB: $145+
MySQLRDS: $145+Cloud SQL: $135+Azure DB: $140+
MongoDBDocumentDB*: $180+Atlas: $200+Cosmos DB: $220+

*DocumentDBはMongoDB互換であり、MongoDB本体ではない

セルフホスト（無料、ただし運用コストを考慮）

3つともオープンソース（MongoDBはSSPLライセンスに懸念あり）。ただし「無料」には含まれない：

  • エンジニアがデータベースを管理する時間
  • バックアップ・リカバリインフラ
  • 高可用性セットアップ
  • セキュリティパッチ

経験則：専任DBAがいるか、大きなコスト制約がない限り、マネージドサービスを使用しましょう。

結論：本音の推奨

ここまで読んでもまだ決められないなら：

PostgreSQLから始めましょう。

PostgreSQLが客観的に「最高」だからではありません—ほとんどのアプリで最高のリスク/リワード比率だからです：

  1. 90%のユースケースをうまく処理
  2. スケールアップしても制限されない
  3. 最高の拡張エコシステム
  4. 業界標準になっているのには理由がある
  5. 後からいつでもMongoDBやRedisを追加可能

MySQLはPHPアプリと読み取り中心のワークロードで、既に専門知識があるなら今でも excellent。

MongoDBは本当にドキュメント指向のデータがある時に価値あり—トレードオフを理解して使いましょう。

データベース戦争はこの時点でほとんど部族的なもの。3つとも本番環境対応で、世界最大のアプリを動かしています。

さあ、何か作りに行きましょう。データベースは大丈夫です。

databasepostgresqlmysqlmongodbbackendsystem-designweb-development

関連ツールを見る

Pockitの無料開発者ツールを試してみましょう

PDF結合
散らばった書類をひとつにまとめましょう。ドラッグ＆ドロップで順番を決め、安全かつ瞬時にPDFを結合します。
使ってみる
PDF分割
必要なページだけを取り出せます。大きなドキュメントを分割したり、特定のページだけを安全に抽出して保存できます。
使ってみる
JSONフォーマッター
乱雑なデータを見た目良く整理しましょう。JSONの構文エラーを自動で修正し、読みやすい形式に整形します。
使ってみる
コード整形・圧縮
1行にギュッと詰まった圧縮コードを読みやすく整形したり、本番用にサイズを小さくしたり。JS、CSS、HTML対応。ブラウザで完結するからコードは外に出ません。
使ってみる
画像圧縮ツール
画像サイズを瞬時に80%削減。画質そのままにPNGとJPGを最適化—完全なデバイス内処理で、プライバシーも万全です。
使ってみる
画像フォーマット変換
画像の互換性を解決します。PNG, JPG, WebPなど、用途に合わせてフォーマットを自由に変換できます。
使ってみる