【比較】PostgreSQLとMySQLの違い¶

概要¶

PostgreSQL と MySQL は、どちらも長年実績のある成熟したオープンソースのリレーショナルデータベース（RDBMS）です。SQL でデータを扱い、ACID トランザクション・インデックス・レプリケーションを備える、という基本は共通しています。「どちらが速い／優れている」と単純比較されがちですが、ワークロード・設定・バージョンに大きく依存するため、ここでは設計思想と機能の方向性で違いを整理します。

PostgreSQL は「オブジェクトリレーショナルデータベース」を標榜し、SQL 標準準拠と拡張性（カスタム型・関数、PL/pgSQL や PostGIS などの拡張、JSONB・配列・範囲型などの豊富なデータ型）に重きを置きます。MySQL は普及の広さと運用エコシステム（豊富なレプリケーション構成、ツール群）が強みで、複数のストレージエンジンを選択でき、既定の InnoDB がトランザクション（ACID）・行レベルロック・MVCC を提供します。なお両者とも MVCC を備える点は共通であり、「MVCC は PostgreSQL だけ」というのは誤りです。

詳細比較¶

比較軸	PostgreSQL	MySQL
位置づけ	オブジェクトリレーショナル DB（SQL を拡張）	リレーショナル DB（標準 SQL ＋拡張）
設計の重心	SQL 標準準拠・拡張性・高度なデータ型	普及・運用エコシステム・ストレージエンジン選択
ストレージエンジン	単一の統合エンジン（WAL ベース）	複数エンジン選択可（既定は InnoDB）
トランザクション/MVCC	コアで MVCC（読みと書きが互いにブロックしない）	InnoDB が ACID・行レベルロック・MVCC を提供
高度なデータ型	JSONB・配列・範囲型・UUID・ユーザー定義型等	JSON・空間型・ENUM/SET 等（拡張性は限定的）
拡張性	拡張機構が豊富（PostGIS、PL 言語多数、FDW 等）	主にエンジン選択とプラグインで対応
レプリケーション	ストリーミング/論理レプリケーション等	レプリケーション/グループレプリケーション/InnoDB Cluster 等

補足：「速さ」はワークロード（読み中心/書き中心、結合の複雑さ、同時実行数）、設定、バージョンに強く依存する。普遍的に「どちらが速い」と断じられる性質のものではない。

よくある誤解¶

誤解1：「MySQL は PostgreSQL より（常に）速い」 — 普遍的には成立しません。性能は読み／書きの比率、クエリの複雑さ、同時実行数、設定、バージョンで大きく変わります。古いベンチマークや一般化されたフレーズを鵜呑みにせず、自分のワークロードで計測するのが正しい姿勢です。「常に速い DB」は存在しません。
誤解2：「MySQL はトランザクション（ACID）非対応」 — 誤りです。既定の InnoDB ストレージエンジンは ACID モデルに従い、コミット・ロールバック・クラッシュリカバリ、行レベルロック、MVCC を備えます。MyISAM など非トランザクショナルなエンジンもあるため「エンジン次第」であり、既定構成では ACID が効きます。
誤解3：「MVCC は PostgreSQL の専売特許」 — 違います。PostgreSQL はコアで MVCC を採用し「読みは書きをブロックせず、書きは読みをブロックしない」ことを掲げますが、MySQL の InnoDB も MVCC（一貫性読み取り）と行レベルロックを提供します。MVCC の有無ではなく実装・既定挙動の違いとして捉えるべきです。
誤解4：「JSON を扱えるのは PostgreSQL だけ」 — 違います。PostgreSQL は JSON/JSONB・配列・範囲型など高度な型が手厚いのは事実ですが、MySQL も JSON 型や空間型を持ちます。差は「型の豊富さ・拡張性の度合い」であって「可否」ではありません。

実務での選び分け¶

「どちらが上か」ではなく「要件と運用前提」で選びます。

複雑なクエリ・高度なデータ型（地理空間=PostGIS、JSONB、配列、ユーザー定義型）や厳密な SQL 標準準拠・拡張性を重視 → PostgreSQL。
既存資産・運用ノウハウ・ホスティングや周辺ツールが MySQL 中心／普及度と人材確保を優先 → MySQL。
ストレージエンジンを用途で使い分けたい（トランザクション要否など） → MySQL（InnoDB を既定にしつつ選択肢を持てる）。
判断軸：①必要なデータ型・拡張（PostGIS 等）②SQL 標準準拠の厳密さ ③チームの習熟・採用エコシステム ④レプリケーション/HA 構成の要件。性能は最終的に自分のワークロードでベンチマークして決める。

ひとことまとめ¶

PostgreSQL も MySQL も成熟した ACID 対応 RDBMS で MVCC を備える点は共通。違いは設計の重心で、PostgreSQL＝SQL 標準準拠・拡張性・高度な型（オブジェクトリレーショナル）、MySQL＝普及・運用エコシステム・ストレージエンジン選択。「常にどちらが速い」と断じず、要件とワークロードで選びます。

出典・参考¶

PostgreSQL 公式「About」（強力なオープンソースのオブジェクトリレーショナルデータベースで SQL を拡張。SQL 標準準拠を重視、JSON/JSONB・配列・範囲型・ユーザー定義型など豊富なデータ型、MVCC、拡張機構（PostGIS、PL 言語、FDW）を備える）: https://www.postgresql.org/about/
PostgreSQL 公式ドキュメント「13.1. Introduction（MVCC）」（MVCC では読み取りのためのロックと書き込みのためのロックが競合せず、読みは書きをブロックせず書きは読みをブロックしない）: https://www.postgresql.org/docs/current/mvcc-intro.html
MySQL 公式ドキュメント「1.2.2 The Main Features of MySQL」（C/C++ 実装、複数のトランザクショナル／非トランザクショナルなストレージエンジン、レプリケーション/グループレプリケーション/InnoDB Cluster、JSON・空間型などのデータ型）: https://dev.mysql.com/doc/refman/8.4/en/features.html
MySQL 公式ドキュメント「17.1 Introduction to InnoDB」（MySQL 8.4 で InnoDB が既定のストレージエンジン。DML は ACID モデルに従いコミット・ロールバック・クラッシュリカバリを備える。行レベルロックと一貫性読み取り（MVCC）をサポート）: https://dev.mysql.com/doc/refman/8.4/en/innodb-introduction.html