■ 1. MySQLのオープンソース性の問題
- 2026年においてMySQLを使用している場合はMariaDBへの移行を検討すべき
- github.com/mysql/mysql-serverへのgitコミット数が2025年に大幅に減少
- MySQLはライセンス上はオープンソースだがプロジェクトとしてはオープンソースではない
■ 2. Oracleによる管理の問題点
- 2009年にOracleがSun MicrosystemsとともにMySQLを買収
- 欧州委員会は競争を抑制する目的があると懸念し買収を阻止しようとした
- OracleはMySQLを維持する約束をしたが良いオープンソースプロジェクトの管理者ではなかった
- コミュニティは長年にわたり衰退
- 開発の問題点:
- すべての開発は非公開で行われる
- 公開されているバグトラッカーはOracle担当者が実際にMySQL開発に使用している本物ではない
- MySQLへの貢献を試みる人々のプルリクエストやパッチ提出は受領としてマークされるがフィードバックはほとんどない
- 変更が次のMySQLリリースに含まれるかどうかは不明で多くの場合書き直される
- gitのauthor/committerフィールドにはOracle担当者のみが記載される
- 実際の著者はブログ投稿で小さく言及されるのみ
- Amazon Web ServicesのRDS MySQLとRDS MariaDBのコアチームのエンジニアリングマネージャーだった際にエンジニアの両方への貢献を監督したがOracleによる貢献の受け入れが悪いためMySQL側への提出を嫌がった
■ 3. MariaDBとの比較
- MariaDBはMySQLの元の作者Michael Wideniusによるフォーク
- すべての開発がgithub.com/mariadb/serverでリアルタイムに行われる
- 誰でもプルリクエストを提出しレビューを受けることができる
- すべてのバグがjira.mariadb.orgで公開討論される
- 真のオープンソースプロジェクトに期待される通りの運営
■ 4. MySQLの技術的衰退
- Oracleは買収後10年以上にわたりMySQL組織を存続させ比較的独立して新バージョンを開発リリースすることを許可した
- MySQL事業は財務的に有用だったと推測されるが少なくともOracleの主要データベース事業を脅かすほど多くの機能を獲得しない限り
- 2022年以降技術的観点から明らかに劣化し始めた
- MySQL 8.0.29の問題:
- デフォルトのALTER TABLEメソッドがin-placeに切り替えられた
- 多くのコーナーケースが機能せずデータベースがクラッシュしデータが破損
- 問題は1年後のMySQL 8.0.32まで完全には修正されなかった
- Oracleが8.0シリーズをevergreenと発表しマイナーリリースで機能と変更を導入した
- ユーザーは歴史的にx.y.Zメンテナンスリリースからバグ修正とセキュリティ修正のみを期待していたため不満
- 新しいメジャーバージョンのリリースが6年間なかった:
- 2018年のMySQL 8.0の後2023年にMySQL 8.1がリリースされたが短期プレビューリリースのみ
- 最初の実際の新しいメジャーリリースMySQL 8.4 LTSは2024年にリリース
- 新しいメジャーリリースにもかかわらずほとんど新機能がなく多くのユーザーが失望
- パフォーマンスの低下:
- 新しいMySQLバージョンでパフォーマンスが低下したという報告が多数
- MySQL性能専門家Mark Callaghanのベンチマークによると書き込み重視のワークロードでMySQL 9.5のスループットは通常8.0より15%少ない
- アップグレードの問題:
- 新しいMySQLバージョンが多くの機能を非推奨にしたため多くのユーザーがMySQL 5.7から8.0および8.0から8.4へのアップグレードで大きな苦労を報告
- 新機能がほとんどなくコードベースのクリーンアップと機能の非推奨に重点が置かれたためOracleがMySQLをかろうじて生かしておくだけと決定したことが明らかになった
- すべての新しい関連機能はOracleのクローズドソースでクラウド専用のMySQL顧客向けサービスHeatwaveに投入
- OracleがMySQLに投資していないことが明らかになりPerconaのPeter Zaitsevが2024年6月にIs Oracle Finally Killing MySQLと執筆
- DB-Enginesによるランク付けでMySQLの人気が急落し始め2026年にはその傾向が加速する可能性
- 2025年9月にOracleが労働力を削減しMySQL担当者が大幅に削減されたとニュースで報道
- MySQLの将来に良い兆候ではなくPeter Zaitsevが11月に最新のMySQLメンテナンスリリースに含まれるバグ修正が以前より少ないことを示す統計を投稿
■ 5. オープンソースの重要性
- オープンソースはイデオロギー以上のものでありソフトウェアのセキュリティと主権に実際の影響を与える
- MySQLが真にオープンソースであるかどうか気にしない人や今後数年間の将来があるかどうか気にしない人がいるが大きなリスクを取っている
- データベースはソフトウェアアプリケーションスタックの最も重要な部分であり運用上の欠陥や問題特にセキュリティ問題は即座に結果をもたらす
- オープンソースでは問題が公開討論され問題が大きいほど多くの人々や企業が修正に貢献する
- オープンソース開発手法は科学的方法に似ており自由なアイデアの流れが常に争われ最も説得力のある証拠を持つものだけが勝つ
- オープンではないことはより多くの不透明性より多くのリスクより多くの信頼してくれという態度を意味する
■ 6. セキュリティ問題の取り扱い
- 2025年だけでMySQLは123件のセキュリティ問題に関するCVEを公開しMariaDBは8件
- 2025年にMySQLのみに影響しMariaDBには影響しなかったCVEは117件
- CVEにはほとんど実際の詳細が含まれていない
- 最新のCVE-2025-53067の例:
- 容易に悪用可能な脆弱性により高権限の攻撃者が複数のプロトコルを介したネットワークアクセスでMySQL Serverを侵害できると記載
- セキュリティ研究者や監査人が元の問題が実際に存在したか修正されたか修正が十分で問題を完全に軽減したかどうかを検証するために使用できる情報がない
- MySQLユーザーはOracleの言葉を信じるしかない
- このようなセキュリティ問題の取り扱いは他のオープンソースプロジェクトとは対照的
- 他のオープンソースプロジェクトでは最初のエンバーゴが終了しCVEが公開された後すべてのセキュリティ問題とそのコード修正が完全な精査のために公開される
■ 7. エンシッティフィケーション
- 真のオープンソースプロジェクトでは見られない様々な形態のエンシッティフィケーションが進行中
- MySQLのソフトウェアドキュメントウェブサイトのすべてがユーザーにオープンソース版の使用を停止しクローズドMySQLバージョン特にHeatwaveへの移行を促している
- Heatwaveはクローズドソースであるだけでなく顧客のデータベースコンテンツをOracleが完全に管理する結果となる
- Redditなどでの話によるとOracleは残りのMySQL顧客から搾り取っており顧客はますます少ないものに対してますます多く支払うことを余儀なくされている
■ 8. 移行の選択肢
- MySQLユーザーの大部分は2010年代半ばに既にMariaDBに切り替えた
- データベースソフトウェアが真にオープンソースであり続けることを深く気にかけた人々が含まれる
- 大規模インストールの例:
- Wikipedia
- FedoraやDebianなどのLinuxディストリビューション
- オープンソースであり統計を収集する中央集権的な機械がないため正確な市場シェアは不明
- アプリケーション固有の統計:
- 世界中のWordPressサイトの57%がMariaDBを実行
- MySQLのシェアは42%
■ 9. 移行方法
- WordPressDrupalMediawikiNextcloudMagentoなどの古典的なLAMPスタックアプリケーションを実行している場合:
- 古いMySQLデータベースをMariaDBに切り替えるのは簡単
- MariaDBはMySQLのフォークでありほとんど後方互換性がある
- MySQLをMariaDBに交換しても既存のコネクタやデータベースクライアントを変更する必要がない
- それらはMariaDBがMySQLであるかのように動作し続ける
- カスタムアプリケーションを実行しデータベースの使用方法と内容を変更する自由がある場合:
- 成熟した十分に機能するオープンソースデータベースが数十ある
- PostgreSQLが最も人気のある一般的なデータベース
- アプリケーションが最初からMySQL用に構築されている場合PostgreSQLへの切り替えには多くの作業が必要な可能性
- MySQL/MariaDBアーキテクチャとストレージエンジンInnoDBは高性能スケーラビリティ堅実なレプリケーション機能が最優先であるオンラインサービスなどで優位性を提供する可能性
- 迅速で簡単な移行にはMariaDBがおそらく最良の選択肢
- Percona Serverへの切り替えも非常に簡単:
- MySQLのすべての変更を密接に追跡しPerconaによる少数の改善によってのみ逸脱
- 基本的にMySQLサーバーのカスタマイズバージョンであるためOracleへの依存を完全に捨てようとする人々にとっては長期的に実行可能なソリューションではない
- MySQLと共通の祖先を持たないがMySQL互換を目指すオープンソースデータベースも複数存在:
- MySQL用に構築されたほとんどのアプリはSQL文を書き直す必要なく単純に切り替え可能
- TiDBの例:
- 非常にスケーラブルで大規模なシステム専用にゼロから設計
- Amazonの最新データベースソリューションDSQLはTiDBから多くのアイデアを借りて構築されるほど優れている
- TiDBは大規模な分散セットアップで真価を発揮するため現在MySQLを使用している大多数の通常の小中規模アプリケーションにとって最も実用的なソリューションはMariaDBへの切り替え
- ほとんどのLinuxディストリビューションでapt/dnf/brew install mariadb-serverを実行するだけでインストール可能
- Oracle以外を選択すれば何を選んでもより良い状況になる