> ## Documentation Index
> Fetch the complete documentation index at: https://villagesql.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# MySQL と PostgreSQL の比較: どちらを使うべきか

> MySQL と PostgreSQL の率直な比較: マネージドサービス、パフォーマンス、型のサポート、拡張性、そしてそれぞれが正しい選択となる場面。

> [card] [VillageSQL is a drop-in replacement for MySQL with extensions.](https://villagesql.com/docs/en/8.4/stable/install-server.md)
>
> All examples on this page work on VillageSQL. Install Now →

MySQL と PostgreSQL はどちらも成熟したオープンソースのデータベースであり、巨大な規模のアプリケーションを支えています。どちらもおもちゃではなく、どちらかが明らかに優れているわけでもありません。両者が持つのは、異なるデフォルト、異なるコミュニティ、そしてトレードオフがあなたに有利に働く異なる場面です。このガイドでは、プロジェクトに合った判断ができるように、こうしたトレードオフを率直に見ていきます。

## MySQL が有利になりやすい場面

**運用のシンプルさ。** MySQL には PostgreSQL よりも厚いマネージドサービスのエコシステムがあります。Amazon Aurora MySQL、Google Cloud SQL for MySQL、Amazon RDS for MySQL はいずれも、長年にわたって本番環境で鍛えられた第一級の製品です。運用の複雑さを自分で抱えずにデータベースを動かしたいなら、MySQL のマネージドの選択肢は優れています。

**主キーアクセスの速度。** InnoDB はクラスタ化インデックスを使用します。つまり、行データは主キーインデックスそのものの中に格納されます。主キーによる検索は 1 回の I/O 操作でデータを取得でき、ヒープからの取得はありません。主にキーに基づく読み取りが中心のワークロードでは、これは意味のある利点です。

**極端な規模での水平スケール。** Vitess は MySQL の上に構築され、YouTube、GitHub、Shopify の MySQL 環境を支えるシャーディング層です。Facebook は、種類を問わずほとんどのデータベースが到達したことのない規模で MySQL を運用していました。水平シャーディングが必要になると見込んでいるなら、MySQL のエコシステムにはよく踏み固められた道があります。

**JSON。** MySQL 8.4 の JSON サポートは堅実です。`JSON_TABLE()` を使えば、JSON の配列やオブジェクトをリレーショナルデータとして扱えます。JSONPath 演算子は WHERE 句の中で自然に動作します。JSON フィールドに生成列を作成し、それにインデックスを付けることもできます。古い MySQL の JSON サポートが弱かったため、今でもこれを過小評価する人がいますが、もう弱くはありません。

**より厳格なデフォルト。** MySQL 8.4 はデフォルトで厳格モードを有効にします。暗黙のデータ切り捨て、ゼロ日付の挿入、ゼロ除算のエラーは、黙って壊されるのではなく捕捉されます。8.0 以前のデータ整合性に関する評判をもとに MySQL を評価しているなら、そうした懸念はおおむね解消されています。

## PostgreSQL が有利になりやすい場面

**拡張性。** これは PostgreSQL の最も明確な構造上の利点です。pgvector、PostGIS、pg\_partman、pg\_trgm など、データベースレベルで型、インデックスメソッド、関数を追加するコミュニティ拡張機能が何百もあります。`CREATE EXTENSION` は PostgreSQL における第一級の概念であり、それを取り巻くエコシステムは厚みがあります。

**より豊富なネイティブ型。** 配列、複合型、範囲型、hstore など、PostgreSQL はデータをモデル化するためのより広い語彙を持っています。アプリケーションが配列や範囲を自然に扱うなら、PostgreSQL では、すべてを子テーブルに正規化したり JSON としてエンコードしたりせずに、データベースの中にとどまることができます。

**標準への準拠。** PostgreSQL はエッジケースにおいて ANSI SQL により忠実です。`RETURNING` 句、`LISTEN`/`NOTIFY`、およびテーブル継承の完全なサポートは、MySQL には存在しないか、動作が異なる機能の例です。標準への準拠がプロジェクトの厳格な要件であるなら、PostgreSQL のほうが安全な選択です。

**部分インデックス。** WHERE 句に一致する行だけにインデックスを付けられます。これは、行の大部分がめったにクエリしない状態にある場合、たとえばアーカイブ済みの注文や論理削除されたレコードがある場合に重要です。MySQL にはこれがネイティブにはありません。

**マテリアライズドビュー。** PostgreSQL には、オンデマンドでリフレッシュできるネイティブのマテリアライズドビューがあります。MySQL にはありません。回避策は、テーブル、ストアドプロシージャ、およびアプリケーションレベルのオーケストレーションの組み合わせです。

**全文検索。** PostgreSQL の `tsvector`/`tsquery` システムは、MySQL の `FULLTEXT` インデックスよりも高機能です。ステミング、ランキング、フレーズ検索はいずれも PostgreSQL 側のほうが表現力があります。

## 機能の同等性

古い評判をもとに MySQL を避けてきたのなら、そうしたギャップの一部は埋まっています。

| 機能 | MySQL 8.4/9.7 | 備考 |
| :- | :- | :- |
| ウィンドウ関数 | あり | 完全サポート |
| CTE (WITH 句) | あり | 再帰 CTE を含む |
| JSON | あり | JSON\_TABLE、JSONPath、生成列 |
| 生成列 | あり | STORED と VIRTUAL の両方 |
| CHECK 制約 | あり | 8.0.16 以降で強制される |
| 不可視インデックス | あり | 削除前にインデックスの除去を安全に試せる |
| ロールベースのアクセス制御 | あり | |
| EXPLAIN ANALYZE | あり | |

不可視インデックスは特に取り上げる価値があります。これは MySQL 固有のものです。インデックスを不可視にしてオプティマイザに無視させ、クエリプランが劣化しないことを確認してから、安全に削除できます。PostgreSQL には同等のものがありません。

## PostgreSQL と比べて MySQL に今も残るギャップ

アプリケーションが次のいずれかに依存しているなら、何が欠けているかを率直に把握しておくことが重要です。

* **配列の列型がない。** 子テーブルに正規化するか、JSON としてエンコードします。
* **部分インデックスがない。** 一般的な回避策は、式を持つ生成列を作り、その列にインデックスを付けることです。機能はしますが、使い勝手は劣ります。
* **ネイティブのマテリアライズドビューがない。** テーブルとスケジュールされたプロシージャで自分で構築します。
* **LISTEN/NOTIFY がない。** データベースレベルの pub/sub が必要なら、MySQL の外側に層が必要になります。
* **テーブル継承がない。** PostgreSQL のテーブル継承モデルに相当するものは MySQL にありません。
* **拡張機能のエコシステムがはるかに小さい。** MySQL のプラグインと UDF のシステムは存在しますが、それを取り巻くコミュニティは PostgreSQL の拡張機能エコシステムに比べて薄いです。

最後のギャップが、ほとんどの開発者が日々実際に感じるものです。

## VillageSQL がギャップを埋める場所

拡張機能のエコシステムは MySQL と PostgreSQL の間で最も具体的な構造上の違いであり、VillageSQL が直接取り組んでいるのがこれです。ベクトル型、ネットワークアドレス型 (INET、CIDR、MACADDR)、暗号関数、UUID v1〜v7、HTTP クライアント関数を、PostgreSQL で `CREATE EXTENSION` を実行するのと同じ方法でインストールできます。サーバーを変更せずに差し込めるインストール可能なバンドルとしてです。

拡張機能は、カスタムのストレージ、比較、演算子のセマンティクスを持つ新しい列型を定義することもできます。これは PostgreSQL で PostGIS や pgvector が使っているのと同じ機能を、MySQL のストレージエンジンに適用したものです。

VillageSQL は内部では今も MySQL です。レプリケーション、InnoDB ストレージエンジン、ワイヤプロトコル、ツールのエコシステム、そのすべてがそのまま残ります。MySQL 向けに構築されたアプリケーションは VillageSQL で動作します。変わるのは拡張性のモデルです。

## MySQL を選ぶべきとき

* チームがすでに MySQL を知っていて、乗り換える説得力のある理由がない。
* マネージドサービスにデプロイする予定で、Aurora、Cloud SQL、または RDS を使いたい。
* 大規模な水平シャーディングが必要になると見込んでいて、Vitess のエコシステムを使いたい。
* ワークロードが読み取り中心で、主キーによるアクセスパターンが支配的である。

## PostgreSQL を選ぶべきとき

* PostGIS または pgvector が必要で、実用的な代替がない。
* アプリケーションが配列、範囲型、または複合型に、正規化すると扱いにくくなるような形で依存している。
* 標準への準拠が、あなたの状況において厳格な要件である。
* チームが PostgreSQL をよく知っていて、逆方向へ移行する圧力がない。

## この決定は取り消せる

今日 MySQL と PostgreSQL のどちらかを選ぶ開発者は、永続的な約束をしているわけではありません。どちらのデータベースも、ほとんどのアプリケーションを数百万ユーザーまで無理なく支えられます。チームが知っているほう、またはクラウドプロバイダーが最も運用しやすくしているほうを選んでください。MySQL を選んだ後で、より豊かな拡張機能のエコシステムが欲しくなったなら、それこそが [VillageSQL](https://villagesql.com/install) が埋めるために作られたギャップです。MySQL のドロップイン代替の上で動く PostgreSQL スタイルの拡張機能です。

## 関連項目

* [PostgreSQL から MySQL への移行](https://villagesql.com/docs/ja/guides/postgres-to-mysql.md) — PostgreSQL の概念と構文を MySQL の同等物に対応付ける
* [MySQL のインデックスの仕組み](https://villagesql.com/docs/ja/guides/mysql-indexes.md) — InnoDB のクラスタ化インデックスの理解と、セカンダリインデックスを追加すべきとき
* [InnoDB のデータ格納方法](https://villagesql.com/docs/ja/guides/innodb-storage.md) — ページ構造、行フォーマット、およびディスク上で起きること
* [MySQL のデータ型の選択](https://villagesql.com/docs/ja/guides/choosing-data-types.md) — データベースを選んだ後に正しい MySQL の型を選ぶ


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.