PostgreSQL vs MySQL — 2026 年に新規プロジェクトならどちらか
読了 5分
新規プロジェクトなら、特別な理由がない限り PostgreSQL を推します。逆に、チームがすでに MySQL の運用経験とツールの上に立っているなら、乗り換える理由もたいていありません。 どちらも成熟したプロダクション級の DB で、ほとんどのワークロードを無理なく支えるので、この記事は優劣論争ではなく「どんな条件ならどちらか」の判断基準の整理です。ちょうど 2026 年 4 月で MySQL 8.0 のサポートが終わり、MySQL 陣営もどのみち 8.4 LTS への移住を決めなければならないタイミングです。
ひと目で分かる比較 #
| 項目 | PostgreSQL | MySQL |
|---|---|---|
| 標準準拠・厳格さ | SQL 標準に忠実、整合性に厳格 | 歴史的に寛容(モードで補完) |
| 機能の幅 | JSONB・配列・範囲型・CTE・ウィンドウ・全文検索を内蔵 | 中核機能は揃うが幅は狭い |
| 拡張エコシステム | pgvector・PostGIS・TimescaleDB などの拡張構造 | 限定的(ストレージエンジンのプラグイン中心) |
| レプリケーション | 物理(ストリーミング)+ 論理、ツールは組み合わせ型 | 論理レプリケーションの歴史が長く運用ノウハウの蓄積 |
| ライセンス・ガバナンス | コミュニティ所有、寛容なライセンス | Oracle 所有、GPL + 商用の二重 |
| バージョンポリシー | 毎年メジャー、各 5 年サポート | LTS(8.4、サポート〜2029/2032)+ Innovation(9.x) |
PostgreSQL に傾く条件 #
- 機能の幅を使う計画があるとき。 JSONB、配列、範囲型、
DISTINCT ON、トランザクションになる DDL(実践マイグレーション編で扱ったあの強み)のように、「別システムなしで DB の中で解決」できる範囲が広いです。ベクトル検索(pgvector)、地理情報(PostGIS)のような拡張まで計算に入れると、差はさらに開きます。 - データ整合性が成否を分けるドメインのとき。 PostgreSQL は不正な値を黙って受け入れる代わりにエラーを返します。MySQL も strict モードが既定になって久しいですが、設計思想の土台が厳格なのは PostgreSQL です。
- エコシステムの方向に乗りたいとき。 新しいフレームワークの既定値、新しいツールのサポート一覧の先頭、マネージド新商品のリリース順が、何年も PostgreSQL 優先です。基礎講座第 1 回で扱った「既定値になった理由」が、そのまま選ぶ理由になります。
MySQL を維持(または選択)する条件 #
- チームと組織の蓄積が MySQL にあるとき。 運用経験、バックアップ・レプリケーションのノウハウ、社内標準、監視の仕組みは、DB の機能より重いです。この蓄積を捨てるコストが PostgreSQL の機能の利得より大きいなら、維持が正解です。
- MySQL 特化のエコシステムに依存するとき。 大規模オンラインスキーマ変更(gh-ost など)、オーケストレーション、プロキシのように、MySQL の大規模運用ツールは検証の歴史が長いです。特に超大型シャーディング運用(Vitess 系)は MySQL 側の資産です。
- プロダクトの要件が単純な OLTP + 実績ある読み取り分散のとき。 この範囲では 2 つの DB の差は体感されず、どちらを選んでも構いません。
ただし MySQL を維持するなら、バージョンの決定が 1 つ残ります。8.0 は 2026 年 4 月でサポートが終わったので 8.4 LTS への移住が事実上必須で(8.4 は 2029 年までプレミアサポート)、9.x は Innovation リリースなので一般のプロダクション用ではありません。
よく出る反論 2 つ #
MySQL のほうが速いのではという問いは、もう事実ではなくワークロードの問題です。単純な PK 参照中心なら MySQL(InnoDB のクラスタ化インデックス)が有利なシナリオがあり、複雑な結合・集計・同時読み書きの混合なら PostgreSQL のプランナが有利なシナリオがあります。ベンチマーク 1 枚で決めず、自分のクエリパターンで判断すべきです。PostgreSQL は UPDATE が高くつくという話は半分だけ正しいです。MVCC の実装上、UPDATE が新バージョンの行を作って VACUUM が後を追う構造は事実ですが、実務の対処(autovacuum チューニング、VACUUM 運用)が確立されており、設計段階で恐れる理由にはなりません。
判断の順序 #
- チームの既存の蓄積(運用経験・ツール・標準)がどちらにあるかから見ます。蓄積があればそちらが既定値です。
- 蓄積がなければ(新チーム・新プロダクト)PostgreSQL を既定値にして、MySQL 特化の要件(超大型シャーディングのエコシステムなど)があるかだけ点検します。
- 機能要件の一覧(ベクトル検索・地理情報・複雑な分析クエリ・JSONB)と照らします。1 つでも中核なら PostgreSQL 側の重みが増します。
- MySQL に決めたなら 8.4 LTS 基準で始めます。8.0 はサポートが終わり、9.x は Innovation です。
まとめ #
- 新規プロジェクトの既定値は PostgreSQL、すでに MySQL の上に立つチームは維持が既定値です。優劣ではなく条件の問題です。
- PostgreSQL の強みは機能の幅(JSONB・拡張・DDL トランザクション)とエコシステムの方向性です。
- MySQL の強みは蓄積された大規模運用ノウハウと特化ツール(オンラインスキーマ変更・シャーディングのエコシステム)です。
- MySQL 8.0 は 2026-04 サポート終了です。維持する場合も 8.4 LTS への移住計画が必要です。
- 性能論争はワークロードの問題です。ベンチマークの引用ではなく自分のクエリパターンで判断してください。PostgreSQL を最初から学ぶなら基礎講座が用意してあります。