1月12日、海外エンジニアのOtto氏が「Stop using MySQL in 2026, it is not true open source」と題した記事を公開した。この記事では、MySQLのオープンソースとしての形骸化と技術的な衰退、そしてMariaDBをはじめとする代替案への移行の必要性について詳しく紹介されている。
以下に、その内容を紹介する。
オープンソースとしての実態とオラクルによる管理体制
2009年にオラクルがサン・マイクロシステムズを買収して以来、MySQLのオープンソースプロジェクトとしての健全性には疑問が呈されてきた。2025年にはGitHub上のコミット活動が著しく減少しており、プロジェクトの停滞が顕著である。
オラクル体制下のMySQL開発は「密室」で行われており、公開されているバグトラッカーは実務で使用されているものとは異なると指摘されている。外部からのプルリクエストやパッチに対するフィードバックは乏しく、採用されたとしても著作者がオラクル職員に書き換えられるケースも少なくない。これに対し、MySQLのフォークであるMariaDBは、リアルタイムで公開開発が行われる真のオープンソースプロジェクトとしての姿勢を維持している。
技術的衰退とパフォーマンスの低下
MySQLは技術的な側面からも劣化が指摘されている。具体的には、以下の点が挙げられる。
- 不安定なリリース管理: MySQL 8.0.29で導入されたALTER TABLEの挙動変更により、データ破損やクラッシュが発生。修正に1年を要した。
- 新機能の欠如と開発の遅延: メジャーバージョンの更新が6年間途絶え、2024年リリースの8.4 LTSでも新機能は限定的であった。
- パフォーマンスの退行: 著名な専門家によるベンチマークでは、書き込み負荷の高いワークロードにおいて、MySQL 9.5の処理能力が8.0と比較して約15%低下していることが示されている。
オラクルは、ベクトル検索などの主要な新機能をクローズドソースのクラウドサービス「Heatwave」に限定しており、オープンソース版のMySQLはメンテナンスのみに留められている。DB-Enginesのランキングでも、MySQLのシェアは急激な下落傾向にある。
セキュリティと透明性の欠如
オープンソースであることは、単なるイデオロギーではなくセキュリティ上の実利を伴う。MySQLでは2025年だけで123件のCVE（共通脆弱性識別子）が公開されたが、その詳細は極めて不透明である。例えばCVE-2025-53067では、脆弱性の検証や修正の妥当性を確認するための情報がほとんど提供されておらず、ユーザーはオラクルの主張を鵜呑みにせざるを得ない状況だ。これに対し、MariaDBの同年のCVEは8件に留まっている。
推奨される代替案と移行の容易性
MySQLからの移行は、多くの場合において容易である。主な選択肢は以下の通りだ。
- MariaDB: MySQLのオリジナル作者によるフォーク。互換性が高く、WordPressなどのLAMPスタックではバイナリを差し替えるだけで動作する場合が多い。
- PostgreSQL: 最も人気のある汎用データベースだが、移行にはSQLの書き換えなどの工数が必要になる可能性がある。
- Percona Server: MySQLに近い構成だが、オラクルへの依存を完全に断つ解決策としては不十分である。
- TiDB: MySQL互換プロトコルを持つ分散データベース。大規模システムに適しており、AWSのDSQLの着想元にもなった。
一般的な中小規模のアプリケーションであれば、MariaDBへの移行が最も現実的である。Linux環境であれば、以下のコマンドでインストールが可能だ。
apt/dnf/brew install mariadb-server
オラクルによる囲い込みと「Enshittification（クソ化）」が進む中、真のオープンソースソフトウェアを選択することは、システムの主権とセキュリティを守る上で不可欠な判断であると言える。
詳細はStop using MySQL in 2026, it is not true open sourceを参照していただきたい。
