![]()
原文地址 https://www.percona.com/blog/how-can-mysql-catch-up-with-postgresqls-momentum/我与 MySQL 社区的前辈交谈时，经常遇到这个问题：「为什么 MySQL 这么棒，而且（至少根据 DB-Engines 的计算）仍然比 PostgreSQL 更流行；但它的地位在下降，PostgreSQL 却势不可挡地越来越受欢迎？」MySQL 生态能做些什么来挽回局势吗？我们来探讨一下！
来看看为什么 PostgreSQL 发展如此强劲，而 MySQL 却在走下坡路。我认为这归结于所有权和治理、许可证、社区、架构和开源产品的发展势头。
所有权和治理
MySQL 从未像 PostgreSQL 那样受到「社区驱动」。然而，当 MySQL 由瑞典小公司 MySQL AB 和 BDFL（仁慈的终身独裁者 -- Benevolent Dictator for Life，一个非正式称号，常用于幽默地称呼开源开发社区项目的发起人）Michael「Monty」Widenious 掌管时，它获得了很多社区的信任。更重要的是，它没有被大公司视为特别的威胁。现在，情况不同了 -- 甲骨文拥有 MySQL，业内许多大公司，尤其云计算厂商，都将其视为对手。当然没有理由为对手贡献代码和营销，创造价值。此外，对于 MySQL，拥有 MySQL 商标的甲骨文公司总是有额外的优先权。
相比之下，PostgreSQL 由社区运行、其所有供应商都立足于一个商业前提：比起 PostgreSQL 生态中的小公司，EDB 这样的公司没有优先权。
这意味着大公司更愿意推荐 PostgreSQL 作为首选，因为这不会为它们的竞争对手创造价值，而且它们对 PostgreSQL 项目的方向有更大的影响力；而数以百计的小公司则通过本地「草根」社区的开发者和市场营销努力，使 PostgreSQL 在全球无处不在。
社区能做的不多 -- 完全取决于甲骨文公司。我在《甲骨文能拯救 MySQL 吗》（见 https://www.percona.com/blog/can-oracle-save-mysql/）中也写到，给 MySQL 一个中立的基础（如跟 Linux 或 Kubernetes 合作），它才有和 PostgreSQL 竞争的机会。我并不乐观，因为我认为，甲骨文目前更感兴趣的是「硬」货币化（译者注：直接通过现有的产品和服务产生营收），而不是增加用户量。![]()
MySQL 拥有双重许可 -- GPLv2 和可以从甲骨文购买到的商业许可；而 PostgreSQL 只有宽松的 PostgreSQL 许可。事实上，这意味着很容易创建有商业许可的 PostgreSQL 衍生分支（如 https://wiki.postgresql.org/wiki/PostgreSQL_derived_databases 所列），或将其嵌入获得商业许可的项目中，不需要任何「变通方式」。当然，开发此类产品的人也在支持和推广 PostgreSQL。MySQL 确实允许云计算厂商创建自己的商业分支，与 MySQL 兼容的亚马逊 Aurora 就是最著名、最成功的此类分支，但在软件发行时却不允许。还是那句话，能做的不多 -- 只有甲骨文公司能根据许可重新授权 MySQL，而我很难相信他们会减少对 MySQL 的控制，尽管采用「开放核心」和「仅限云」模式的软件，通常与采用宽松式许可「核心」的软件可以结合得很好（原文：even though「open core」and「cloud only」editions often play well with permissively licensed「core」software）。![]()
我认为，当我们考虑开源社区时，最好考虑三个而不是一个社区。（见 https://peterzaitsev.com/there-are-three-open-source-communities-not-just-one/）说到用户社区，MySQL 的表现仍然相当出色，尽管 PostgreSQL 越来越多地成为新应用程序的首选。不过，用户社区往往是其他社区工作的成果。PostgreSQL 中，贡献者社区更强大，这是由许多组织推动的。我们举办了针对贡献者的活动，还编写了关于如何为 PostgreSQL 作出贡献的书籍。PostgreSQL 的扩展架构也有助于轻松扩展 PostgreSQL，并公开分享工作成果。供应商社区 -- 这才是主要问题，没那么多公司有兴趣推广 MySQL，因为这样只是在为甲骨文公司创造价值。 那么，这不会鼓励所有甲骨文「合作伙伴」去推广 MySQL 吗？ 有可能，全球范围内也确实有一些由合作伙伴支持的 MySQL 活动，但这些无法与供应商对 PostgreSQL 的支持相提并论，因为PostgreSQL是「他们的项目」。这次我不会说社区已经无能为力。其他领域的现状使工作更困难，回报也更少，但社区仍然可以做很多事情。 如果你关心 MySQL 的未来，请组织并参与各种活动，尤其是在 MySQL 社区之外。你可以写文章、录视频、写书，在社交媒体上推广，并将它们提交给 Hacker News。尤其不要错过 FOSDEM 2025 MySQL Devroom 的征集活动！（见 https://www.mysqlandfriends.eu/）甲骨文公司也可以在不减少盈利的情况下参与。与潜在贡献者接触 -- 发起外部贡献者可以参与的活动，与他们分享计划，支持他们的贡献，至少在他们与 MySQL 社区蓝图相一致的情况下。
![]()
一些 PostgreSQL 用户把 PostgreSQL 的发展势头归因于其更好的架构和更简洁的代码库。我认为这不是主要原因，但值得讨论。
PostgreSQL 的设计实现了大量功能强大的扩展，而 MySQL 只有有限的扩展可能性。最大的例外是存储引擎接口，MySQL 支持多种存储引擎，而 PostgreSQL 只支持一种（尽管 Neon 或 OrioleDB 这样的分支可以通过打补丁来改变）。
这种可扩展性使 PostgreSQL 易于创新（尤其在拥有更强大的贡献者社区的情况下），且无需纳入核心代码。即使 MySQL 的可扩展性有限，利用其已有的各种插件和组件，也还是可以做很多事情的。（插件见 https://dev.mysql.com/doc/extending-mysql/8.0/en/plugin-types.html；组件见 https://dev.mysql.com/doc/refman/8.4/en/components.html）
首先需要针对 MySQL 插件的社区市场，这将鼓励开发者构建更多插件，且容易关注。 我们还需要甲骨文的支持 -- 承诺扩展 MySQL 插件架构，支持开发者构建插件，即使它们会与甲骨文的产品竞争。 例如，如果 MySQL 拥有创建自定义数据类型和可插拔索引的插件，也许就已经有用于 MySQL 的 PNG 向量替代方案。![]()
选择数据库是一个长期的赌注，因为更换并不容易。问问那些几十年前选择甲骨文，现在又被它困住的人就知道了。这就意味着，选择数据库时需要考虑未来：不仅希望所选的数据库十年后还会存在，而且要考虑它是否会随着时间推移而发展，以满足未来的技术需求。正如我在文章《甲骨文最终会杀死 MySQL 吗》（见 https://percona.com/blog/is-oracle-finally-killing-mysql/）中所写，甲骨文已将大量开发者的重心转移到专有和 Cloud-only MySQL 版本上，MySQL Community 几乎已废弃。MySQL 在今天许多应用中仍非常出色，但它的确落后了，MySQL 社区中许多人质疑它是否适合未来的发展。再次强调，MySQL 的发展主要取决于甲骨文公司，因为是他们一手推进了 MySQL 的官方路线。至于 Percona Server for MySQL？我们确实提供了甲骨文 MySQL 的领先开源替代方案，但必须注意所作的改变，以免破坏完全兼容性或使上游合并成本过高。MariaDB 则作出了不同的权衡；不受限制的创新使其与 MySQL 的兼容性越来越差，而且每个版本的差异也越来越大。![]()
MariaDB 由 MariaDB 基金会管理，不是已经尽可能地解决了所有这些问题吗？ 别急！我认为，MariaDB 是一个有缺陷的基金会（见 https://www.percona.com/blog/open-source-and-flawed-foundations/），它并不拥有所有的知识产权，尤其是商标，无法为所有供应商提供公平的竞争环境。它仍然存在商标垄断问题，因为只有一家公司能提供 MariaDB 的所有东西。不过，MariaDB 可能有机会；MariaDB（公司）刚被 K1 收购（见 https://k1.com/k1-acquires-mariadb/），管理和商标所有权有机会发生变化，更接近 PostgreSQL 的情况。只是私募股权公司不擅长减少对商标知识产权的控制，所以希望不大。MariaDB 基金会可以将其更名为 *SomethingElse*DB，从而获得对该项目的完全商标控制权，但这意味着 MariaDB 将失去其所有的知名度；这种情况不太可能发生。MariaDB 与 MySQL 也有很大区别，协调两者之间的差异需要多年的努力。但只要有足够的资源和社区意愿，这是可以解决的。总结
如你所见，由于 MySQL 的所有权和管理方式，社区的活动受到了限制。长远来看，MySQL 社区与 PostgreSQL 竞争的唯一途径是所有重要的参与者联合起来（就像 Valkey（https://valkey.io）那样），在不同的品牌下创建一个 MySQL 替代方案 -- 这可以解决上面提到的大多数问题。
Next Stack 技术联盟成立：推动中国基础软件发展，迈向全球创新舞台
Bytebase 3.0 - 数据库 DevSecOps
Bytebase 产品介绍
Bytebase & CloudCanal 联合解决方案
![]()
