PostgreSQLとMySQLの違いは？実務でどう選ぶかを初心者向けに比較

Q: Q. JSON 型はどちらが強いですか？

A. PostgreSQL の jsonb は GIN インデックスと含有演算子 @> で、パスを事前に全部知らなくても柔軟に検索できます。MySQL 8.0 の JSON も実用範囲ですが、検索したいパスごとに生成列＋関数インデックスを用意する設計になり、条件が増えるたび追加が要ります。

Q: Q. PostgreSQL の方が機能が多いと聞きますが具体的には？

A. 再帰 CTE、豊富なウィンドウ関数、jsonb、配列型、ENUM 型、複数のインデックスタイプ（BTree、GIN、GiST、BRIN）、論理レプリケーション、PL/pgSQL の高度なストアド、citext や PostGIS などの拡張、が代表例です。

先に要点

PostgreSQL は拡張性や高度な機能を活かしたい案件で強く、MySQL は情報量の多さや既存環境との相性で広く使われています。どちらが上という話ではありません。
判断は抽象論より具体シナリオで。JSON を集計検索する管理画面なら PostgreSQL、既存 LAMP の受託案件なら MySQL のように、案件の形から逆算すると迷いません。
個人開発や一般的な Web アプリならどちらでも十分戦えます。最初は「既存環境に合わせる」「チームが触り慣れている方」でも合理的です。
後から乗り換えると、大文字小文字の照合や AUTO_INCREMENT の扱いなど見えにくい移行コストが出ます。「最初に正しく選ぶ」価値はここにあります。

「PostgreSQL と MySQL、結局どっちがいいの？」「Laravel ならどっちを選ぶべき？」

この比較は定番ですが、「速いらしい」「高機能らしい」という断片だけで判断するとズレます。本当に見るべきは、何を作るのか、どんな運用にするのか、チームがどこまで扱えるのか です。

この記事では PostgreSQL 公式ドキュメントと MySQL 8.4 リファレンスマニュアルを確認しつつ、PostgreSQL と MySQL の違いを、初心者にも分かるように実務目線で整理します。一般論で終わらせず、実際のコマンドと典型的な出力、そして乗り換えで踏みやすい地雷まで踏み込みます。

まず結論：どちらも定番、ただし得意分野が少し違う

最初に結論を書くと、PostgreSQL も MySQL も、どちらも十分に実務で使われている定番の RDBMS です。そのうえで、ざっくりした傾向はこうです。

観点	PostgreSQL	MySQL
全体の印象	高機能・拡張性が高い	広く使われていて導入しやすい
向きやすい場面	複雑な検索、厳密なデータ処理、将来の拡張	一般的な Web アプリ、情報量重視、既存環境への適合
初学者の入りやすさ	少し理屈が多め	触れる情報が多く入りやすい
実務での選び方	要件を伸ばしたい案件で強い	無難に始めやすい案件で強い

「片方が古い・片方が新しい」という話ではありません。実務では 案件の性質とチーム事情で選び分ける のが自然です。以下では、まずこの「案件の形から逆算する」具体例を 2 つ示します。ここがこの記事の中心です。

ケースで見る：この案件ならどっちを選ぶか

抽象的な比較表は判断に使いにくいので、実際に持ち込まれやすい 2 つの案件を例に、なぜそちらを選ぶのかまで書きます。

ケースA：JSON を集計検索する管理画面 → PostgreSQL

イベントログや問い合わせフォームの回答など、項目が案件ごとに変わる半構造データを保存し、「どの項目に何件あったか」を管理画面で日々絞り込み集計する、というよくある案件です。型が固まらない列は JSON に逃がし、その中身で検索・集計したくなります。ここは PostgreSQL の jsonb と GIN インデックスが効きます。

ケースB：既存 LAMP の受託・保守案件 → MySQL

共用サーバーや既存 VPS で動いている WordPress 改修、古い PHP 業務システムの追加開発、引き継ぎ案件など。すでに MySQL が前提で、バックアップ手順も保守会社の慣れも MySQL ベース。ここで機能差だけを理由に PostgreSQL へ寄せると、運用全体が重くなって損をします。素直に MySQL を使うのが正解です。

ケースAで PostgreSQL が効く理由（コマンドつき）

回答データを jsonb 列に持ち、その中の値で検索・集計する例です。

-- PostgreSQL：jsonb 列に GIN インデックスを張る
CREATE TABLE responses (
  id   bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  data jsonb NOT NULL
);
CREATE INDEX idx_responses_data ON responses USING gin (data jsonb_path_ops);

-- 「plan が pro の回答だけ」を絞り込む（含有演算子 @>）
SELECT count(*) FROM responses WHERE data @> '{"plan":"pro"}';

EXPLAIN をかけると、件数が増えても全件走査ではなく GIN インデックスを使う計画になります。典型的な出力はこうです。

Aggregate
  ->  Bitmap Heap Scan on responses
        Recheck Cond: (data @> '{"plan": "pro"}'::jsonb)
        ->  Bitmap Index Scan on idx_responses_data
              Index Cond: (data @> '{"plan": "pro"}'::jsonb)

ポイントは、JSON のキーや値を 事前に全部知らなくても 含有検索が 1 本のインデックスで効くことです。項目が増えても張り直しが要りません。MySQL でも同じことはできますが、MySQL の JSON は「検索したいパスごとに、生成列＋関数インデックスを先に用意する」発想になります。

-- MySQL 8.0系：JSON の特定パスを取り出した生成列にインデックスを張る
ALTER TABLE responses
  ADD COLUMN plan VARCHAR(20)
    AS (data->>'$.plan') STORED,
  ADD INDEX idx_plan (plan);

SELECT count(*) FROM responses WHERE plan = 'pro';

これは速いのですが、後から「region でも絞りたい」「tags 配列に含まれるか調べたい」となるたびに列とインデックスを足す必要があります。絞り込み条件が育つ管理画面ほど PostgreSQL が楽、というのがケースAの結論です。

ケースBで MySQL を素直に使う理由

ケースBは技術的な優劣ではなく運用の話です。共用サーバーの管理パネルが MySQL/MariaDB しか持たない、保守ドキュメントもダンプ手順も mysqldump 前提、引き継ぎ先のエンジニアが MySQL に慣れている――この状況で PostgreSQL に替えると、「少し有利な機能」と引き換えに「手順・教育・障害対応のすべてを作り直すコスト」を背負います。受託・保守では 運用全体で無理がない方が正義 です。

PostgreSQLとは何か

PostgreSQL は、オープンソースで長く使われている高機能なリレーショナルデータベースです。公式ドキュメントでも、堅牢性、拡張性、標準 SQL への準拠、高度なデータ型やインデックス機能が特徴として整理されています。

初心者向けにざっくり言うと「標準的な Web アプリにも使えるし、少し複雑な要件まで伸ばしやすいデータベース」です。実務で名前が出やすい理由は次のような点です。

jsonb など JSON 系の扱いが比較的強い
インデックスの種類が多い（BTree、GIN、GiST、BRIN など）
拡張機能（PostGIS、pg_trgm など）でできることが広い
データの整合性を重視する案件で選ばれやすい

MySQLとは何か

MySQL も、世界的に非常に広く使われているオープンソースのリレーショナルデータベースです。公式ドキュメントでは InnoDB を中心に、トランザクション、外部キー、全文検索、JSON、レプリケーションなど、一般的な Web システムに必要な機能がそろっています。

初心者向けに言うと「まず普通の Web アプリを作る」場面でかなり困りにくいデータベースです。実務で選ばれやすい理由は次の通りです。

利用例が多く、日本語情報も含めて調べやすい
レンタルサーバーや既存環境で採用されていることが多い
LAMP 系の定番構成として慣れている人が多い
小さく始めるときの心理的ハードルが低い

PostgreSQLとMySQLの違いを実務目線で見る

1. 機能の伸びしろは PostgreSQL が目立ちやすい

複雑な条件検索、柔軟な型、拡張、分析寄りのクエリなどを考え始めると、PostgreSQL の強みが見えやすくなります。特に jsonb、豊富なインデックス、拡張機能の世界は「あとから要件が増えそう」な案件と相性がよいです。

一方で、MySQL も JSON、全文検索、ウィンドウ関数（8.0 以降）など実務で必要な機能はかなりそろっています。そのため 一般的な CRUD 中心の Web アプリなら MySQL でも十分 という場面は多いです。

2. 情報量と触りやすさは MySQL が有利になりやすい

MySQL は長く Web 開発の定番だったので、日本語情報も含めて非常に多いです。「エラーが出たときにまず調べやすい」「既存の構成例を見つけやすい」という意味で、初学者には助かります。

逆に PostgreSQL は、高機能なぶん「どこまで使いこなすか」の判断が必要になることがあります。ただし基本的な使い方まで難しいわけではありません。

3. 厳密さや拡張性を見に行くなら PostgreSQL が候補に上がりやすい

業務システムやデータ処理系では、あとから検索条件が複雑になる、JSON をかなり使う、インデックス設計が重要になる、拡張機能を活かしたくなる、といったことが起きます。こうしたとき PostgreSQL は「後から伸ばしやすい」と感じやすく、将来の自由度まで見て選ぶチームは少なくありません。

4. 既存環境との相性は MySQL が勝つことも多い

レンタルサーバー、古くからある LAMP 構成、社内の既存運用、バックアップ手順、保守会社の慣れなどを見ると、MySQL が前提の場面はまだ多いです。実務では「技術的に少し有利」より「運用全体で無理がない」方が大事なことも多い、という前述のケースBの話です。

ハマりやすい移行コスト：MySQL から PostgreSQL へ替えたら検索が空振りした

「最初に正しく選ぶ」価値を実感しやすいのが乗り換えです。よくある失敗を、現象・原因・確認手順・回避の形で 1 つ示します。

現象

MySQL で動いていたログイン機能を PostgreSQL へ移行したら、ユーザーが正しいはずのメールアドレスでログインできなくなった。検索系も「Tanaka で登録したのに tanaka で検索すると 0 件」になる。

原因

MySQL の既定照合（utf8mb4_general_ci など _ci 系）は大文字小文字を区別しない。PostgreSQL の文字列比較は既定で区別する。WHERE email = 'Foo@Ex.com' が MySQL では当たっていたが、PostgreSQL では別物として扱われ空振りする。

確認手順はシンプルです。移行先の PostgreSQL で、実際に当たらない値を 2 通りで試します。

-- 大文字小文字をそのまま比較（PostgreSQLでは区別される）
SELECT count(*) FROM users WHERE email = 'Tanaka@example.com';
--  count
-- -------
--      0

-- 小文字化して比較すると当たる → 照合の問題だと切り分けられる
SELECT count(*) FROM users WHERE lower(email) = lower('Tanaka@example.com');
--  count
-- -------
--      1

回避策は用途で選びます。メールアドレスやユーザー名のように本来区別したくない列は、大文字小文字を区別しない型に寄せるのが定石です。

citext 拡張（CREATE EXTENSION citext; 後に列を citext 型に）を使い、比較を自動で大小無視にする
もしくは保存時に lower() で正規化し、検索も lower() 同士で比較する（関数インデックス CREATE INDEX ON users (lower(email)) を併用）

このほか移行で踏みやすい地雷として、MySQL の AUTO_INCREMENT は PostgreSQL では GENERATED ALWAYS AS IDENTITY や serial に置き換えが必要で、移行ツールによっては連番が引き継がれず「整数列のまま採番が止まる」ことがあります。さらに識別子のクォートが MySQL はバッククォート、PostgreSQL はダブルクォートで、二重引用符付きの識別子は大文字小文字を区別するため、流用した SQL が静かに壊れます。MySQL が許す「ゼロ日付」（0000-00-00）も PostgreSQL は受け付けません。こうした崩れは最初の DB 選択で多くが避けられる、というのが移行の教訓です。

Laravelならどちらを選ぶべきか

Laravel は、PostgreSQL にも MySQL にも対応しています。ORM である Eloquent が差を吸収してくれるので、Laravel だからどちらか一択になるわけではありません。実務的な見方は次の通りです。

状況	向きやすい選択
既存環境や運用手順が MySQL 前提	MySQL を素直に使う
新規構築で将来の拡張性も重視	PostgreSQL も有力
チームの多くが MySQL に慣れている	MySQL の方が立ち上がりやすい
複雑な検索や JSON 活用を見込む	PostgreSQL が候補に上がりやすい

注意点として、Eloquent が吸収するのは主に基本的な CRUD までです。whereJsonContains のような JSON 系メソッドや生 SQL を使い始めると、前述の照合差や JSON 関数の違いが表に出ます。「ORM だからどっちでも完全に同じ」と思い込まず、本番と同じ DB で開発・テストするのが安全です。

どんな案件で PostgreSQL が向きやすいか

検索条件が複雑で、後から要件が増えそう（前述のケースA）
JSON データや柔軟なクエリを活かしたい
分析寄りの集計や高度な SQL（ウィンドウ関数、再帰 CTE）を使うことが多い
長期的に機能を伸ばしながら育てたい
最初から DB 設計の自由度を高く持ちたい

要するに「少し凝ったことをしたくなる未来が見える案件」と相性がよいです。

どんな案件で MySQL が向きやすいか

一般的な Web アプリや業務アプリを無難に作りたい
情報量の多さや人材の慣れを重視したい
既存運用や保守体制が MySQL 寄り（前述のケースB）
レンタルサーバーや共用環境に寄せたい
まず早く形にして、複雑さを増やしすぎたくない

つまり「普通の Web アプリを着実に回す」文脈では、MySQL はかなり扱いやすいです。

初心者ならどちらから触るべきか

初心者なら無理にこだわりすぎなくて大丈夫です。学び始めの段階では、どちらも SQL の基本やテーブル設計の考え方は共通しています。

そのうえで、すでに触れる環境があるならその方、会社や案件で使っている方、学習記事や周辺ツールが手元に多い方、から入るのが現実的です。

完全にゼロから選ぶなら、次のステップ感で十分です。

読み込み中...

よくある誤解

PostgreSQL の方が新しくて上位互換？

そういう話ではありません。PostgreSQL は高機能ですが、MySQL も長く実務で使われていて、一般的な Web 開発には十分強いです。

MySQL は簡単だけど本番向きではない？

そんなことはありません。多くの本番環境で使われていますし、実務実績も豊富です。

PostgreSQL は難しすぎて初心者向きではない？

高度な機能まで踏み込むと考えることは増えますが、基本的な CRUD や SQL まで極端に難しいわけではありません。必要以上に怖がらなくて大丈夫です。

PostgreSQLとMySQLに関するよくある質問

Q. パフォーマンスはどちらが速いですか？

A. 単純な参照中心では MySQL の InnoDB が速いケースが多く、複雑なクエリや集計、並行書き込みでは PostgreSQL が安定しやすい傾向です。前述のケースAのように JSON の集計検索を伸ばすなら PostgreSQL が有利になりやすい、と用途で考えるのが実務的です。

Q. JSON 型はどちらが強いですか？

A. PostgreSQL の jsonb は GIN インデックスと含有演算子 @> で、パスを事前に全部知らなくても柔軟に検索できます。MySQL 8.0 の JSON も実用範囲ですが、検索したいパスごとに生成列＋関数インデックスを用意する設計になり、条件が増えるたび追加が要ります。

Q. 開発で MySQL、本番で PostgreSQL のような構成は問題ありますか？

A. 推奨しません。本記事の移行コストの章の通り、大文字小文字の照合、型の扱い、エラーメッセージ、トランザクション特性が違い、本番で初めて気づくバグが出ます。本番と同じ DB を開発でも使うのが基本です。

Q. MySQL から PostgreSQL へ移行するとき、最初に気をつける点は？

A. 「静かに壊れる」三点が要注意です。(1) 文字列比較の大文字小文字（PostgreSQL は既定で区別）、(2) バッククォート識別子（ダブルクォートへ置換が必要で、置換すると大小区別が発生）、(3) ゼロ日付や AUTO_INCREMENT の引き継ぎ漏れ。移行後はログインや検索など照合に依存する機能を真っ先にテストしてください。

Q. PostgreSQL の方が機能が多いと聞きますが具体的には？

A. 再帰 CTE、豊富なウィンドウ関数、jsonb、配列型、ENUM 型、複数のインデックスタイプ（BTree、GIN、GiST、BRIN）、論理レプリケーション、PL/pgSQL の高度なストアド、citext や PostGIS などの拡張、が代表例です。

Q. レプリケーションや高可用性はどちらが楽ですか？

A. 業界全体では MySQL の方が情報が多く構築事例も豊富です。PostgreSQL も論理／物理レプリケーションの両方が使え、Patroni などの HA ツールがそろっています。チームが慣れている方を選ぶのが現実的です。

Q. クラウドのマネージドサービスはどちらが多いですか？

A. どちらも主要クラウドで提供されています。AWS RDS、Cloud SQL、Azure Database はどちらも対応。近年は PostgreSQL 向けに Supabase、Neon、Aurora PostgreSQL のようなサーバーレス系が増えており、新規ならこの選択肢の広さが効きます。

Q. 学習コストの違いはありますか？

A. 基本的な SQL なら大差ありません。MySQL の方が情報量が多く入門書も豊富です。PostgreSQL は標準 SQL に忠実で「正しく書けば動く」印象が強いと言われます。

まとめ

PostgreSQL と MySQL は、どちらも実務で十分使われる定番のデータベースです。違いは「使える／使えない」ではなく、どんな案件により合いやすいか にあります。

判断は抽象論より具体で。JSON を集計検索する管理画面のように条件が育つなら PostgreSQL、既存 LAMP の受託・保守のように運用が固まっているなら MySQL、と案件の形から逆算すると迷いません。そして後から乗り換えると照合や採番の地雷を踏むので、「最初に正しく選ぶ」価値は思った以上に大きいです。最終的には「チームが扱いやすいか」「今の運用に無理がないか」がかなり効きます。

DB だけでなくサーバー全体の置き方まで整理したいならクラウド、VPS、レンタルサーバーの違いは？コスパ比較と実務での使い分けを解説もつながります。Laravel を土台にした開発の向き不向きまで見たいなら Laravelとは？何が作りやすくて、どんな案件で強いのかを解説もあわせてどうぞ。

参考リンク

PostgreSQL Documentation: About PostgreSQL
PostgreSQL Documentation: JSON Types
PostgreSQL Documentation: Indexes
PostgreSQL Documentation: citext
MySQL 8.4 Reference Manual: The InnoDB Storage Engine
MySQL 8.4 Reference Manual: The JSON Data Type
MySQL 8.4 Reference Manual: Optimizing Queries with EXPLAIN