MySQLとPostgreSQLの違いを徹底解説：用途・パフォーマンス・機能を比較

読者の皆さん、こんにちは！
データベースの選定はシステム開発の中でもっとも重要な決断の一つです。今回は、MySQL と PostgreSQL という2大代表的オープンソース RDBMS を徹底的に比較し、用途・パフォーマンス・機能を網羅的に解説します。どちらが自社のアプリに適しているか、迷っているエンジニアの疑問に答えるため、実際に触れた上でメリット・デメリットを整理していきます。

技術的背景と歴史

MySQL は 1995 年にドイツの開発チームが発表しました。シンプルかつ高速な CRUD 操作を重視し、ウェブアプリケーションでの人気を集めました。2008 年に Sun Microsystems に買収され、2010 年には Oracle へと移管。現在は MariaDB をはじめとしたフォークが並び、企業版の MySQL Enterprise Edition も提供されています。

PostgreSQL は 1996 年に PostgreSQL Global Development Group によって開発が始まりました。最初は Ingres の先駆者であったリサーチ・グループが進化させたもので、ACID の完全な実装や拡張性を重視しています。Oracle など商用データベースと比較しても機能面では追いつきつつあります。

権利とライセンス

• MySQL: GPL v2（コミュニティ版）＋ 商用ライセンス（MySQL Enterprise）。
• PostgreSQL: PostgreSQL License（MIT 風）で、ほぼ「自由」だと評価されています。

GPL の方針ではソースコードを公開したいという前提がありますが、商用に閉じる場合は別途ライセンスが必要です。PostgreSQL は制限が少なく、プロジェクトに組み込む際にコストが落ちるケースが多いです。

SQL 標準準拠度

PostgreSQL は SQL 標準に非常に忠実です。CTE（WITH 句）やウィンドウ関数、サブクエリ結合など、標準的な機能を満たしています。これらは移植性が高く、他の RDBMS への移行が容易です。一方 MySQL は標準から外れた独自構文（例：LIMIT … OFFSET）の実装が多く、標準遵守はやや低めです。

データ型とストレージエンジン

データ型

• MySQL: INT, VARCHAR, TEXT, DECIMAL, DATETIME, BLOB など。JSON 型（MySQL 5.7+）も追加。
• PostgreSQL: さらに ENUM, CIDR, TSVECTOR, JSONB など、標準以外の型が充実。

PostgreSQL の JSONB はバイナリ形式で格納され、検索が高速。MySQL の JSON はテキストベースで検索コストが高いケースも出ます。

ストレージエンジン

• MySQL: 近代は InnoDB が標準。以前は MyISAM など多様。MySQL 8 で統一は進むものの、エンジン切替が可能な点も残る。
• PostgreSQL: 単一のストレージエンジン。ファイルシステムレベルで最適化されているため、追加のエンジン管理が不要。

InnoDB は ACID を保証しつつ、行レベルロックと高速なトランザクションを提供。しかし、PostgreSQL は MVCC（Multi-Version Concurrency Control）によりほぼ全操作をロックフリーで行うので、同時アクセス時の輻輳が少ないことが強みです。

参照整合性と外部キー

• MySQL: InnoDB が外部キーに対応。ただし、以前は MyISAM ではサポート無し。デフォルトでは RESTRICT が多いが、設定により ON DELETE CASCADE なども可能。
• PostgreSQL: 内蔵外部キー制約が堅牢。DEFERRABLE（遅延検証）など高度な設定が可能。

PostgreSQL の外部キーはデフォルトで即時検証（NOT DEFERRABLE）、必要に応じて遅延検証を使える柔軟性があります。これにより、複雑なバッチ処理でもトランザクション内で一括処理が可能です。

取引と ACID

• MySQL: InnoDB は ACID を完全サポート。バイナリログを利用したレプリケーションで高可用性も実現。
• PostgreSQL: Write-Ahead Logging（WAL）で信頼性を確保。pg_xact がトランザクションの整合性を管理。非常に高い耐障害性を持つ。

パフォーマンスに関しては、MySQL はシングルスレッドで高速な読み取りを行いやすく、短いトランザクションで効果的。PostgreSQL は MVCC によって同時書き込み時に影響が少ない設計となっているため、長期トランザクションでもデータ損失が起きにくいです。

同期処理の制御

• MySQL: 行レベルロック（REPEATABLE READ でのロック管理）。SELECT ... FOR UPDATE などで明示的にロック。
• PostgreSQL: MVCC により“仮想版”を生成。全てのトランザクションは最新スナップショットを取得し、障害が起きてもデータロックのリスクが低い。

大規模な同時アクセス環境では PostgreSQL の MVCC が優勢です。MySQL はそのシンプルさが利点だが、ロック競合が多いとスループットが低下します。

インデックスと検索性能

インデックスタイプ

• MySQL：全文検索エンジンはサーバ内に実装されており、FULLTEXT インデックスは速度が良い。ですが、MySQL の全文検索は英語や日本語などの形態素解析が機能しないことがある。
• PostgreSQL：tsvector と tsquery を使った全文検索で高度な形態素解析が可能。さらに、外部ライブラリ（pg_tsearch2）で日本語対応を拡張できる。

ユニーク制約とパフォーマンス

PostgreSQL はインデックス作成時に「ハッシュ」「BTREE」「GIN」「GiST」など多様な方式を選択でき、実行計画により最適化できます。MySQL 8 も GHOST インデックスや BRIN などが追加されましたが、まだ PostgreSQL の方が柔軟です。

パーティションとシャーディング

• MySQL: ハイブリッド、ハッシュパーティション、レンジパーティションなどに加え、クラスタ上での分散機能は主に第三者製（ProxySQL 等）。
• PostgreSQL: Declarative Partitioning（2016 で正式導入）により柔軟なパーティションをネイティブで実装。さらに、PGXC や Citus（PostgreSQL の分散版）で横方向のスケールアウトも容易。

長期保管や大量データの OLAP では PostgreSQL のパーティション機能が手軽に利用できます。MySQL のパーティションは分割は簡単ですが、統合が難しいケースがあります。

フルテキスト検索と JSON

PostgreSQL の JSONB は「B-Tree」「GIN」「GiST」のインデックスをサポートし、数十秒で数十万件の検索が可能です。MySQL は JSON にはインデックスがないため、検索は文字列検索に頼るしかありません。

触発的機能：ストアドプロシージャ、関数、トリガー

• MySQL: 変数や制御構文が少ない。プラグイン言語（C, Python）で拡張可能。ストアドプロシージャは SQL のみに限られ、性能コストはやや大きい。
• PostgreSQL: PL/pgSQL のほか、PL/Python, PL/Perl, PL/Java など多様。関数は戻り値を持つ RETURNS で柔軟に設計でき、カーソル関数も扱える。トリガーは NEW/OLD 行を直接操作できる。

PostgreSQL の関数は IMMUTABLE・STABLE・VOLATILE として性能を最適化できるのが魅力です。MySQL はトリガーも使えますが、複雑さは低めです。

GIS と PostGIS

• MySQL: Geometric 型（POINT, LINESTRING など）は標準だが、GIS 用の拡張（MySQL GIS Functions）は機能制限が多い。MySQL 8 からは geo パッケージで簡易的に拡張。
• PostgreSQL + PostGIS: 世界最大級のオープンソース GIS 拡張。GEOMETRY, GEOGRAPHY 型、オーバーレイ分析、距離計算、トポロジー解析が標準でサポート。

GIS で何らかの空間解析を行う場合は、PostgreSQL + PostGIS が圧倒的に優れています。

冗長化・複製・バックアップ

PostgreSQL は pg_basebackup と WAL アーカイブで「ポイントインタイムリカバリ」が簡単。MySQL は binlog で同等ですが、復旧手順はやや面倒です。大規模クラスタでは PostgreSQL の WAL ベースストリーミングレプリケーションが信頼性高く、MySQL の Galera などは複雑性が増します。

スケーラビリティとクラウド導入

• MySQL: 既存クラウド（RDS, Aurora, Cloud SQL, GCP MySQL）でのサポートが充実。水平スケールは主に読み取りオフロード（read replica）に限定。Aurora は独自に高速化。
• PostgreSQL: RDS、Aurora（PostgreSQL compatible）や Cloud SQL で広く利用。Citus でシンプルに分散テーブル化でき、PostgreSQL の拡張性が高い。PGBouncer, Pgpool-II で接続プールも成熟。

クラウドベンダーの提供するマネージドサービスでは、料金体系やサポート体制が同等になることも多く、選択は機能要件や既存技術に依存します。

エコシステムとツールセット

PostgreSQL には pgAdmin はもちろん、 psql の \d コマンドでテーブルを簡易的に確認できるようなCLIヘ теппが強力です。MySQL でも似たような mysql CLI が存在しますが、PostgreSQL のクエリプランやインデックス統計情報はより詳細です。

価格対価の評価

• MySQL: サーバ内での設定が簡潔で、短時間の開発スプリントに向いています。
• PostgreSQL: 機能豊富でスケールに耐える設計ですが、学習曲線がやや急峻。パフォーマンスチューニングには時間が要ります。

使いどころと事例

実務での選択指針

1. データ量と同時書き込み
   • 大規模同時書き込みや長時間トランザクションが多い場合 → PostgreSQL
2. 全文検索の粒度
   • 高度な形態素解析を必要とする場合 → PostgreSQL
3. GIS を必要とする
   • 高度な空間解析が必要の場合 → PostgreSQL + PostGIS
4. クラウドサービスで Aurora
   • Aurora の高速化を活かす場合 → MySQL
5. 単純な読み取りだけでスケールアウト
   • Read Replica を主要にするとき → MySQL

まとめ

結論
既存の業務アプリケーションでシンプルにスケーラブルであり、高速な読み込みが必要なら MySQL*。
*長期トランザクション、複雑な空間解析、フルテキスト検索の高度化、オープンソースでの拡張性を重視するなら PostgreSQL がベスト。

これで何が変わる？

• データ整合性：MySQL はシステムの簡易さがメリットだが、MySQL 8 の INNODB はスケールアップをしやすい。
• 検索性能：PostgreSQL の全文検索と JSONB がデータ取得を大幅に高速化。
• GIS：PostgreSQL + PostGIS が圧倒的にパワフル。
• スケーラビリティ：Citus で横方向に分散化できる点が Postgres の優位。
• 開発・運用：pgAdmin などCLIと統合された高度な統計情報により、トラブルシュートが楽。

もし要件が 「同時取引と高可用性 + 高度な検索機能」 を両立させるなら PostgreSQL を選択に検討すべきです。
逆に 「読み取りが主体、短いトランザクションで高速で単一リーダー/ライトサーバ」 が重要なら MySQL が向いています。