由 John Doe 一月 30, 2026
Dave Stokes 曾是 MySQL AB 公司的员工，下面是他对于 MySQL 用户未来选择的分享。那么，对于 Oracle 用户未来的选择，又会怎么样呢？
目录
撰写这篇博文，我并非有意冒犯任何人，也绝非轻视那些令我敬佩的杰出人才的付出。但在 2025 年假期期间，我与不少人交流时，他们都提出了同一个问题：MySQL 的未来究竟在何方？即将召开的开源开发者欧洲会议（FOSDEM）上，多场活动都将探讨这一话题，并主推某种特定解决方案。但在我看来，这些方案在诸多方面都存在偏差。
长久以来，甲骨文公司（Oracle）就未曾对 MySQL 社区版进行实质性改进。他们裁掉了 MySQL 团队的众多核心骨干。在甲骨文接手这款 “全球最受欢迎数据库” 后的近十五年里，它确实为我们带来了不少价值，对此我们理应心怀感激。但如今，这一阶段已然落幕。对于不再有更新、不再修复漏洞、也不再有创新的 MySQL 社区版，是时候考虑其他替代方案了。
目前有以下几种选择可供参考。
维持现状，不作任何改变
第一种选择就是什么都不做。许多人至今仍在使用版本老旧、早已停止维护的 MySQL。市面上还存在大量 MySQL 5.7 的运行实例。尽管该软件的后续版本新增了不少亮眼功能，但如果这些功能并非必需，那为何要升级呢？对于那些不太需要 JSON、物化视图这类功能的用户而言，MySQL 一直以来的极简特性颇具吸引力。在 “只要没坏就别乱动” 的软件管理理念下，这种维持原状的做法，会成为许多人的默认选择。
优点：无需进行任何改动。
缺点：会背负沉重的技术债务，如同泰坦尼克号进水一般，积重难返。这种方式或许还能撑上几年，但前路危机四伏。
选择 PostgreSQL
那 PostgreSQL 呢？这是一款极为优秀的数据库，拥有众多实用功能，是个稳妥的选择。将 MySQL 的数据库模式和数据迁移至 PostgreSQL 的过程也相对简便。迁移后，你需要部署连接池，时刻关注清理（VACUUM）操作的状态，还得从数量繁多的索引选项中挑选合适的类型，不过 B+ 树或许仍是你的首选。PostgreSQL 的一大显著优势是，它的性能每年都在稳步提升。从长远来看，这是个明智的选择。但对许多人而言，这种迁移的改动幅度太大，门槛过高。
为什么这么说？ 对于长期使用 MySQL 的用户而言，PostgreSQL 的配置流程要复杂得多。它就像一把功能齐全的瑞士军刀，拥有丰富的选项和扩展插件，但这也意味着操作难度更高。它的复制配置流程，感觉就像在拼装儿童积木玩具一样繁琐。而且，如果你不懂得如何监控事务 ID 回卷问题，很可能会因此栽跟头。MySQL 在运维上基本可以做到 “设置好就不用管”，而 PostgreSQL 则需要投入更多精力去维护。
优点：这是搭建健壮、真正开源数据库的理想选择，也是我大多数时候会给出的推荐方案。
缺点：它存在一些看似陈旧的长期问题，而且运维过程中需要时刻留意。
选择 MySQL 的衍生或分支版本
MariaDB
MariaDB 在十五年前从 MySQL 分叉而来。在多数情况下，从 MySQL 迁移至 MariaDB 并不困难，除非你大量使用 JSON 功能或 MySQL 集群。MariaDB 最近收购了 Galera 集群，该集群与 MySQL 集群的复制理念类似，但二者并不兼容。MariaDB 吸纳了不少从甲骨文 MySQL 团队离职的顶尖人才。它与 MySQL 有着深厚的渊源，但如今二者在发展路线上早已分道扬镳。对于部分用户来说，它或许是个 “足够接近” 的替代选项。
优点：这可能是仅次于维持现状的、迁移难度第二低的方案，而且它还具备一些 MySQL 社区版没有的实用功能。
缺点：MariaDB 存在一些设计粗糙的部分，比如它的 JSON 功能实现，不过这对你可能没有影响。此外，过去几年间，其基金会的闹剧、公司运营风波、上市遇挫以及 SkySQL 相关的种种争议，也让不少人对它望而却步。
Percona MySQL
多年来，Percona 一直在基于甲骨文官方的 MySQL 进行优化改进，其大部分营收也来源于 MySQL 相关业务。它开发了不少实用功能，这些功能其实早该被甲骨文纳入官方版本中。这款数据库非常稳定，与甲骨文的产品极为接近。但问题在于，如果上游的 MySQL 官方停止更新，下游的 Percona 又将何去何从？而且随着 Galera 集群被 MariaDB 收购，Percona 分支版本的用户是否会被迫迁移至 MariaDB 呢？此外，Percona 内部的人员流动率也较高，这可能会对其分支版本的发展造成影响。
优点：这是最贴近甲骨文官方 MySQL 的替代方案。
缺点：若甲骨文彻底放弃 MySQL，Percona 能否扛起 MySQL 生态的大旗？目前来看，可能性不大。
Oracle 企业版 MySQL
当然，你也可以选择付费使用甲骨文的企业版 MySQL。Percona 的一位创始人曾直言，甲骨文其实根本没有所谓的 “客户”，只有 “人质”。
过去五十年来的计算机行业发展史中，不乏那些赌定拉里・埃里森（甲骨文创始人）会失败，最终却铩羽而归的人。
但要为一款曾经免费的产品付费，实在让人难以接受。
优点：从社区版切换至企业版的流程十分简便。
缺点：这种切换带来的最直观感受，就是钱包会大幅缩水。而且甲骨文还会不定期进行合规审计。
云数据库服务
在过去十年里，对于那些不想自己运维数据库、宁愿花钱让别人代劳的人来说，云数据库服务是个绝佳选择。云服务商承担起数据库运维的责任，你只需要挑选心仪的数据库产品即可。在某种程度上，不同云服务商提供的关系型数据库产品，功能都大同小异。再搭配一两个对象关系映射框架（ORM），数据库的底层差异几乎就被完全抽象掉了。
你完全可以将所有数据库相关工作都交给云服务商，让他们去处理那些繁琐的后台运维事务，就像当初你不再操心磁盘阵列（RAID）的管理一样。
优点：数据库相关的问题，从此都由别人来解决。
缺点：成本高昂，而且需要对云服务商的运维能力给予高度信任。
其他兼容 MySQL 的数据库
除了上述选项，还有不少与 MySQL 兼容的数据库。我个人比较青睐 TiDB。但 “兼容” 并不等同于完全 “等同” 于 MySQL。这些数据库性能表现出色，在很多方面甚至优于 MySQL。但如果你只是想快速搭建一个实例用于概念验证，或是给孩子所在的体育联盟搭建一个小型应用，这些数据库就显得有些大材小用了。不过，对于大型项目而言，它们或许正是你需要的理想选择。
优点：在一定程度上与你熟悉的 MySQL 兼容。
缺点：可能并非你的刚需之选，而且兼容性或许并不完全达标。
结语
时间和市场最终会筛选出优胜者。这个赢家或许不在上述列表之中，可能会有全新的数据库产品横空出世，如同骑着独角兽的英雄一般，一举解决我们所有的难题。但对此，我们也不必抱有过高期待。
我的预测是：甲骨文退出 MySQL 社区版市场后，其份额将由上述多种方案共同瓜分。其中占主导地位的两种选择，一是持续向 PostgreSQL 迁移，二是维持现状，继续使用当前版本的 MySQL 社区版。前者适合那些追求顶尖技术方案、着眼于未来技术迭代的用户，毕竟 PostgreSQL 的贡献者们一直在持续为其带来新的改进。后者则适合那些秉持 “不折腾运行良好的系统” 理念的用户。
大多数人最终可能会选择 PostgreSQL。这是一个坚实可靠的技术选择，在一群专注投入的优秀团队的维护下，它的性能逐年提升，能满足你超出预期的需求。
但我依然会怀念 2007 年我加入 MySQL AB 公司时的那种氛围。那时的我们，相信一切皆有可能。近二十年后的今天，这样一个曾经充满活力的项目，如今却步履蹒跚地走向停滞，实在令人惋惜。
参考
Dave Stokes：Is the future of MySQL PostgreSQL?