なぜMySQLは9.0にならなかったのか

MySQL8.0の次が9.0でないのは“技術的理由”ではない

MySQL8.0の次は普通に考えると9.0です。
しかし実際に登場したのは8.1、8.2、8.3、そして8.4でした。

これは開発が遅れたわけでも、9.0にできなかったわけでもありません。
理由は単純で、9.0にすると「壊れる」と思われるからです。

ソフトウェアのバージョン番号は、開発者のためのものではありません。
利用者の心理をコントロールするための情報でもあります。

特にデータベースでは、その意味が大きくなります。

メジャーバージョンが持つ“意味”

多くのエンジニアは、メジャーバージョンをこう解釈します。

• 大きく変わる
• 互換性が壊れる
• 移行コストが高い

実際、MySQL5.7から8.0への移行は簡単ではありませんでした。
SQLの挙動、認証方式、設定、文字コードなど、広い範囲に影響しました。

その経験があるため、もし「MySQL9.0」が発表されると、多くの企業はこう判断します。

「しばらく様子見しよう」

つまり、導入が遅れるのです。

MySQL8.0は“継続進化型”に変わった

従来のMySQLの考え方

かつてのMySQLは、5.5 → 5.6 → 5.7 → 8.0 というように、
メジャーバージョンごとに大きな変化を入れていました。

しかしこの方式には問題があります。

• 移行のたびに大規模検証が必要
• ユーザーがアップグレードを避ける
• 古いバージョンが残り続ける

結果として、5.6や5.7が長期間使われ続けました。
これはセキュリティ的にも好ましくありません。

そこで変わったリリースモデル

MySQL8.0以降は、リリースモデルが変わりました。

• 大きな破壊的変更を減らす
• 小さく頻繁に進化させる
• 移行の心理的負担を下げる

つまり「次の世代」を作るのをやめ、同じ世代を育て続ける方式になりました。

その結果が8.1、8.2、8.3、8.4です。

9.0にしなかった本当の理由

最大の理由は“企業システム”です。

企業のデータベースは、次の特徴を持ちます。

• 10年以上稼働する
• 年1回しか更新できない
• 承認プロセスがある

ここで9.0が出ると何が起きるか。

• 移行検証が必要
• 監査説明が必要
• 予算が必要

つまり「導入できない」状態になります。

MySQLの開発側にとって最悪なのは、
新しいバージョンが使われないことです。

8.xを継続させることで、ユーザーはこう認識します。

「同じ系統だから大丈夫そう」

この安心感が、実は最も重要です。

8.4という番号の意味

8.4は偶然の数字ではありません。
これはリリースモデルの区切りを示しています。

MySQLは次の構造になりました。

• 8.1〜8.3：Innovation Release
• 8.4：LTS

つまり8.4は9.0の代わりではなく、8.0系の完成版です。

9.0という名前にすると「次世代DB」に見えてしまいます。
それを避けるための番号です。

実際に起きる現場の反応

興味深いのは、バージョン番号が運用判断に直接影響する点です。

例えば次の2つを比べます。

• MySQL9.0へ移行
• MySQL8.4へ更新

技術的には後者の方が変更点が多くても、
心理的には8.4の方が安全に見えます。

現場ではこうなります。

• 9.0：会議が増える
• 8.4：パッチ扱いになる

これは技術ではなく組織の問題です。
しかしデータベースは組織の中で使われるソフトウェアです。

バージョン番号はマーケティングでもある

ソフトウェアのバージョンは単なる数値ではありません。

• 安心感
• 導入判断
• サポート契約

これらに直結します。

MySQLはかつて「技術中心」の製品でした。
現在は「採用されること」が重要になっています。

9.0を出すより、8.xを続けた方が導入は進みます。

よくある誤解

「9.0がない＝進化していない」

これは逆です。
むしろ現在のMySQLは、過去より速いペースで改善されています。

違うのは“変え方”です。

以前：大きく壊して進化
現在：壊さず進化

これはクラウド時代のソフトウェアの典型的な進化モデルです。

最後に

MySQLが9.0にならなかったのは、技術的な問題ではありません。
データベースが“製品”から“社会インフラ”へ変わったからです。

データベースに求められるのは革新性ではなく継続性です。
8.xが続くのは停滞ではなく、安定を優先した結果です。

バージョン番号を見れば、ソフトウェアの技術だけでなく、
そのソフトウェアが置かれている世界の変化も見えてきます。