「PostgreSQLの方がシェアが高くなった」は本当？
「PostgreSQLがMySQLを抜いて1位になった」という記事を見て、驚いた方も多いのではないでしょうか。
Stack Overflow開発者調査（2024年版）によると、確かにPostgreSQLの利用率は51.9%で、MySQLの39.4%を上回っています。
わずか6年前の2018年には、MySQLが59%、PostgreSQLが33%だったことを考えると、劇的な逆転です。
しかし、「じゃあこれからはPostgreSQLを選べばいいのか？」と単純に考えるのは危険です。
この記事では、社内SEの視点から「どちらを選ぶべきか」を解説します。シェアの数字だけでなく、日本の現場での実態やシェアが低い技術を選ぶリスクも含めてお伝えします。
グローバルのシェアと日本の現場は違います。実務で何を重視すべきか、一緒に考えましょう💡
シェアの数字を鵜呑みにしてはいけない理由
「PostgreSQLがシェア1位」という情報には、いくつか注意点があります。
調査によって結果が異なる
| 調査 | 1位 | 2位 | 備考 |
|---|---|---|---|
| Stack Overflow（2024） | PostgreSQL 51.9% | MySQL 39.4% | 開発者への直接調査 |
| DB-Engines Ranking | Oracle | MySQL | 検索エンジン・求人等から算出 |
Stack Overflowの調査は「開発者が使っている」データベースの調査です。一方、DB-Enginesは検索トレンドや求人情報などから算出しており、企業システム全体ではまだMySQLやOracleが優勢です。
MariaDBを含めるとMySQL系が1位
MariaDBはMySQLから派生したデータベースで、互換性があります。MySQLとMariaDBを合算すると、MySQL系が依然として1位という見方もできます。
日本の現場とグローバルは違う
グローバルでPostgreSQLのシェアが上がっていても、日本の現場ではMySQLが圧倒的に多いのが実態です。
- レンタルサーバーはほぼMySQL標準、PostgreSQL対応は少数
- WordPress、EC-CUBEなど主要CMSはMySQL前提
- 日本語の情報・書籍はMySQLの方が豊富
- MySQL経験者の方が採用しやすい
「シェアが高い＝正解」ではありません。自社の環境に合った選択が重要です🔍
シェアが低い技術を選ぶリスク
社内SEとして技術選定をする際、シェアが低い技術を選ぶリスクは必ず考慮すべきです。
これはPostgreSQLに限らず、どんな技術にも当てはまる普遍的なリスクです。
リスク1：人材確保が難しくなる
シェアが低い技術は、経験者が少ないため採用が難しくなります。
- 求人を出しても応募が来ない
- 派遣・SESで人材を探しても見つからない
- 単価が高くなりがち
- 担当者が退職すると引き継ぎ先がいない
特に中小企業では「この技術ができる人がいなくなったらどうするか」は深刻な問題です。
リスク2：情報が少なくトラブル対応に時間がかかる
シェアが低い技術は、日本語の情報が少ない傾向があります。
- エラーメッセージで検索しても解決策が見つからない
- StackOverflowの回答が英語のみ
- 書籍が少ない、あっても古い
- ベンダーに問い合わせても「事例がない」と言われる
トラブル発生時に「ググっても出てこない」状況は、社内SEにとって致命的です。
リスク3：対応サービス・ツールが限られる
レンタルサーバー、SaaS、監視ツールなど、周辺サービスの対応状況にも差が出ます。
| 項目 | MySQL | PostgreSQL |
|---|---|---|
| レンタルサーバー対応 | ほぼ全て | 一部のみ |
| WordPress対応 | ◎ | ×（非公式プラグインあり） |
| GUIツール | phpMyAdmin等多数 | pgAdmin等あり |
| クラウドマネージドDB | ◎ | ◎ |
リスク4：ベンダーロックインの裏返し
「シェアが低い技術を選んだ結果、その技術に詳しい特定のベンダーに依存してしまう」というケースもあります。
結果として、高額な保守費用を払い続けることになったり、ベンダーの都合に振り回されることになります。
リスク5：将来のサポート終了・衰退リスク
シェアが低い技術は、開発が停滞したり、サポートが終了するリスクがあります。
ただし、PostgreSQLとMySQLはどちらも成熟したOSSであり、近い将来に消滅するリスクは低いです。この点では両者とも安心して選べます。
技術選定は「今」だけでなく「5年後、10年後」も考える必要があります。人材確保・情報量・サポート体制は重要な判断基準です⚠️
PostgreSQLが伸びている理由
では、なぜPostgreSQLのシェアが急上昇しているのでしょうか。主な理由を整理します。
理由1：AI時代への対応（ベクトル検索）
生成AIの普及により、ベクトル検索への対応が重要になっています。
PostgreSQLは「pgvector」という拡張機能でベクトル検索に対応しており、AI関連のプロジェクトで採用されるケースが増えています。
理由2：クラウド大手の採用
AWS、Google Cloud、Microsoft Azureなど、主要クラウドベンダーがPostgreSQLベースのマネージドサービスを提供しています。
- AWS：Amazon Aurora PostgreSQL、Amazon RDS for PostgreSQL
- Google Cloud：Cloud SQL for PostgreSQL、AlloyDB
- Azure：Azure Database for PostgreSQL
理由3：Oracle所有への懸念
MySQLは2010年にOracleに買収されました。オープンソースでありながら、開発方針がOracle次第という状況に懸念を持つ開発者も少なくありません。
一方、PostgreSQLは非営利団体「PostgreSQL Global Development Group」が管理しており、特定企業に依存しない点が評価されています。
理由4：高度な機能と標準SQL準拠
PostgreSQLは機能面でMySQLより優れている点が多くあります。
- 標準SQLへの準拠度が高い
- JSONデータの扱いが柔軟
- GIS機能（PostGIS）が強力
- 複雑なクエリ・大規模データに強い
MySQLとPostgreSQLの技術的な違い
社内SEとして押さえておくべき技術的な違いをまとめます。
| 項目 | MySQL | PostgreSQL |
|---|---|---|
| 得意な処理 | 読み取り重視のWebアプリ | 読み書き両方、複雑なクエリ |
| SQL標準準拠 | やや低い | 高い |
| トランザクション | InnoDB使用時はACID準拠 | デフォルトでACID準拠 |
| JSONサポート | あり | より高機能 |
| GIS機能 | 基本的 | PostGISで高機能 |
| ベクトル検索 | 弱い | pgvectorで対応 |
| 学習コスト | 低め | やや高め |
| 運営 | Oracle社 | 非営利コミュニティ |
コマンドの違い（移行時の注意点）
MySQLとPostgreSQLでは、一部のコマンドや記法が異なります。移行時には注意が必要です。
| 機能 | MySQL | PostgreSQL |
|---|---|---|
| 自動採番 | AUTO_INCREMENT | SERIAL / GENERATED AS IDENTITY |
| 文字列結合 | CONCAT() | || 演算子 |
| 真偽値 | TINYINT(1) | BOOLEAN |
| 識別子の囲み | バッククォート ` | ダブルクォート “ |
| LIMIT句 | LIMIT 10, 5 | LIMIT 5 OFFSET 10 |
用途別：どちらを選ぶべきか
社内SEとして新規システムを構築する際の選定基準をまとめます。
MySQLを選ぶべきケース
| 用途 | 理由 |
|---|---|
| WordPress / EC-CUBE | アプリがMySQL前提 |
| レンタルサーバー利用 | PostgreSQL非対応の場合が多い |
| 読み取り中心のWebアプリ | シンプルで高速 |
| 社内にMySQL経験者が多い | 学習コスト・引き継ぎリスク低減 |
| 日本語情報を重視 | 書籍・Web情報が豊富 |
PostgreSQLを選ぶべきケース
| 用途 | 理由 |
|---|---|
| クラウド（AWS/GCP/Azure）前提 | マネージドサービスが充実 |
| 複雑なクエリ・大規模データ | 高度な機能と信頼性 |
| GIS（地理情報）を扱う | PostGISが強力 |
| AI/機械学習連携 | pgvectorでベクトル検索対応 |
| JSONを多用するアプリ | 柔軟なJSONサポート |
| Oracle依存を避けたい | コミュニティ運営で安心 |
どちらでもよいケース
- クラウドのマネージドDBを使う場合（両方対応している）
- VPS/専用サーバーで自由に構築できる場合
- 社内に両方の経験者がいる場合
既存システムは移行すべきか？
「PostgreSQLのシェアが上がったから、既存のMySQLシステムを移行すべきか？」という疑問もあるかもしれません。
結論：基本的に移行する必要はありません。
移行しなくてよい理由
- MySQLは今後も十分なサポートが継続される
- 移行にはコスト・リスクが伴う（SQL書き換え、テスト、ダウンタイム）
- 動いているシステムを無理に変える必要はない
- PostgreSQLでなければ実現できない機能がなければ不要
移行を検討すべきケース
- システムリプレースのタイミング
- クラウド移行と同時に検討
- PostgreSQL固有の機能（GIS、ベクトル検索等）が必要になった
- Oracle依存への懸念が経営判断として重要
「シェアが逆転したから移行」は本末転倒です。今のシステムが問題なく動いているなら、そのままで大丈夫です👍
社内SEとしての現実的な対応
最後に、社内SEとして取るべき現実的な対応をまとめます。
1. 両方触れる人材を育てる
MySQLしか知らない、PostgreSQLしか知らない、という状況はリスクです。
基本的なCRUD操作やバックアップ・リストアは、どちらのDBでもできるようになっておくと安心です。
2. 新規システムは用途に応じて選定
「社内の標準はMySQL」と決めつけず、プロジェクトの要件に応じて柔軟に選定しましょう。
クラウド前提のシステムであれば、PostgreSQLも積極的に検討する価値があります。
3. 既存システムは無理に移行しない
動いているシステムを「シェアが変わったから」という理由で移行するのはナンセンスです。
リプレースやクラウド移行のタイミングで検討すれば十分です。
4. 技術トレンドは継続的にウォッチ
PostgreSQLの躍進は「AI時代への対応」が大きな要因です。
今後も技術トレンドは変化していくので、定期的に情報収集しておくことが重要です。
まとめ
| ポイント | 内容 |
|---|---|
| シェア逆転 | Stack Overflow調査ではPostgreSQLが1位（51.9%） |
| ただし注意 | 調査によって結果は異なる。日本ではMySQL優勢 |
| PostgreSQL躍進の理由 | AI対応、クラウド採用、Oracle依存回避 |
| シェア低い技術のリスク | 人材確保難、情報不足、サービス対応の制限 |
| 既存MySQLシステム | 無理に移行する必要なし |
| 新規システム | 用途に応じて柔軟に選定 |
| 社内SE対応 | 両方触れる人材育成、トレンドウォッチ |
選定の基本方針：
WordPress / EC-CUBE → MySQL一択
レンタルサーバー利用 → MySQL（対応状況を確認）
クラウドマネージドDB → どちらでもOK
複雑なクエリ・GIS・AI連携 → PostgreSQL推奨
社内に経験者がいる方 → その技術を優先「PostgreSQLのシェアが上がった」というニュースに振り回される必要はありません。
大切なのは、自社の環境・要件・人材に合った選択をすることです。
どちらも優れたデータベースです。トレンドに惑わされず、現場に最適な選択をしましょう😊
コメント