本文作者：尹海文，Oracle ACE Pro，PostgreSQL ACE，IvorySQL 专家委员会成员，10 年数据库行业经验。公众号：胖头鱼的鱼缸。

这些天看到 Stack Overflow 2026 全球开发者调研，数据库方向又是 PostgreSQL 第一，57.9%。

看到“又第一了”，我当然知道这说明 PG 受欢迎：开发者愿意用，生态也在持续变大。不过榜单一出来，很多讨论很容易顺手多走一步，把“开发者用得多”说成“企业生产用得最多”。 这一步，证据还没跟上。

所以这篇文章想泼的冷水，泼在榜单的口径上，不是泼在 PostgreSQL 身上。

一、57.9%到底在统计什么

Stack Overflow 原题是：

Which database environments have you done extensive development work in over the past year? Which do you want to work in over the next year?

中文大意是：过去一年，受访者在哪些数据库环境中做过大量开发工作，明年又想继续使用哪些数据库。

数据库这道题是可选题，也是多选题。数据库部分有 12,061 份有效回答，PostgreSQL 被 6,984 人选择，所以得到 57.9%。这里的分母是回答数据库问题的人，不是整份调查的所有人。

图 1：这张图把“总调查人数”“数据库问题回答数”和“PostgreSQL 选择人数”分开画出来，百分比的分母不能混用。

这个 57.9% 表示的是： 在这批回答了数据库问题的人里，有多少人过去一年在 PostgreSQL 上做过大量开发。它没有回答下面这些问题：

• PostgreSQL 有多少个生产实例；
• PostgreSQL 承载了多少数据和交易；
• 有多少企业把它放进关键业务；
• 出故障时有没有 7×24 小时的支持和责任承接。

调查总共有 30,903 份有效回答，覆盖 169 个国家； 官方方法说明显示，数据库问题本身是可选的，调查又是通过 Stack Overflow 网站、博客和邮件列表面向社区成员推广的。 12,061 对描述这个社区的开发者选择来说不算小，对推断全球开发者和企业生产规模来说却不是一个足够的样本。

这里的“不够”，主要不是简单地嫌数字小，而是抽样对象和问题维度都对不上。假设从全球开发者名册里随机抽样，12,061 份回答可以有不错的比例精度；现在的样本来自自愿参与的 Stack Overflow 社区，而且没有询问生产实例数量、数据规模和业务关键性，统计误差再小，也不能把它变成全球生产市场份额。

二、这个第一名到底说明了什么

它首先说明 PostgreSQL 在开发者这一层很强： 容易开始，能力够宽，扩展方便，遇到问题也容易找到文档、示例和同行讨论。

一个开发者做新项目时，往往希望先把业务模型搭起来，再决定要不要接入空间、全文、向量或其他能力。PostgreSQL 的关系模型、SQL、事务和扩展机制，正好让很多验证工作可以在同一个数据库里完成。开源协议和云上的托管选项，又把第一次使用的门槛压低了。

这类优势会反映在开发者调查里：一个人可能在本地、测试环境、个人项目和正式项目里都用过 PG；一个团队也可能因为 ORM、容器镜像和云服务都准备好了，先用它把产品跑起来。

图 2：同一个数据库的“有人用”“企业采用”和“承载关键生产业务”是三件不同的事。

所以我认可这个第一名的价值：它说明 PG 已经成为很多开发者默认会考虑的数据库，也说明相关人才、工具、教程和云服务会继续增加。

但它不能直接推出“PG 已经是企业生产第一”。 开发者榜单测的是“我用起来顺不顺手”，企业生产还要继续问“它能不能长期稳定跑，出了问题谁来接”。

三、开发者榜单和生产环境，看的根本不是一张表

两种排名的统计对象不一样。开发者调查把人当作回答单位；企业生产更常见的单位是实例、集群、组织、存储容量、交易量或业务系统。

SQLite 在这张榜单上是第二名，42.1%。这并不奇怪：它大量出现在嵌入式应用、移动端、测试和本地工具里。它的开发者覆盖度很高，不能据此推导它在大型企业中心数据库里的服务器规模。

Oracle 在开发者问卷中的比例是 9.4%，看起来远低于 PostgreSQL；但很多 Oracle 系统运行在金融、制造、运营商和大型政企的长期核心业务里，真正需要关注的是它承载的业务、数据和责任，而不是有多少开发者在问卷里勾了它。

一个开发者可以同时选择 PostgreSQL、MySQL、Redis 和 SQLite；一家企业也可能同时运行 Oracle、SQL Server、PostgreSQL、Redis 和数据仓库。 多选调查适合描述技术接触面，不适合计算单一数据库的生产市场份额。

DB-Engines 2026 年 10 月的快照排在前面的也是 Oracle、MySQL、Microsoft SQL Server 和 PostgreSQL，但它使用网页提及、搜索热度、技术讨论、招聘信息、LinkedIn 资料和社交媒体等指标。DB-Engines 在 排名方法说明里也明确写着：这个排名 不测量安装数量，也不测量数据库在 IT 系统中的实际使用量。

企业侧的数据库调查同样很少给出全球实例总量。 Redgate 的 2026 年数据库环境报告提供了另一个观察角度：其页面列出的 2025 数据显示，84% 的组织使用两个或更多数据库平台，其中 53% 使用两到三个，23% 使用四到五个，8% 使用五个以上。这个数据不能用来证明某个数据库的生产份额，却能说明企业生产往往是多平台并存，治理成本不会因为某一个开发者榜单第一就自动消失。

图 3：同样叫“使用量”，换一个统计单位，排名就可能换一套。

目前没有一份权威、完整、公开的全球生产数据库普查，可以告诉我们 Oracle、MySQL、SQL Server、PostgreSQL 各自到底有多少生产实例、承载多少交易和数据。 遇到“全球数据库生产排名”时，第一件事应该是追问统计口径，而不是先拿名次下结论。

四、PG 为什么容易被开发者喜欢

把 PG 用于快速搭建和验证，我认为完全合理。

数据库的关系模型、SQL、事务和约束，可以让开发者先把业务模型表达清楚；扩展机制又允许团队在需要时增加空间、全文、向量或其他能力。很多项目不用一开始就拆成好几个专用系统，验证路径自然会短一些。

这就是 PG 的开发者优势： 起步快，试错成本低，功能边界可以按项目逐步往外推。

问题也恰好藏在这里：开发阶段只需要把方案跑通，生产阶段还要为它的每一次变化负责。开发者看到的是“这个扩展能不能装、这个查询能不能跑”；生产团队还要问“升级以后还能不能用、坏了谁修、出了问题能不能退回去”。

图 4：开发者能够快速开始，不代表企业已经完成了生产交付。

五、社区驱动，不等于不专业

这里需要把“社区驱动”说准确。

PostgreSQL 的上游项目确实由全球社区推动，但这个社区里有 Core Team、Committer、Security Team、CommitFest 和代码评审流程。 项目治理页面和 Committer 说明写得很清楚：很多开发者和公司长期参与贡献，提交的代码会经过其他提交者和社区的审查。

所以，“社区驱动”描述的是项目的治理和贡献方式，不是“没人负责”或者“代码质量没有门槛”。

扩展生态则要单独评估。PostgreSQL 官方文档把随源码提供的 contrib 模块和独立开发的外部扩展分开说明，PostGIS 就属于独立项目。扩展可以像内置能力一样工作，但 “能安装”不等于“天然具备企业级支持”。

不同扩展的维护者、测试覆盖、版本兼容、升级路径、安全响应和商业支持可能差别很大。个人或小团队维护的项目不必然不专业，大型团队维护的项目也不能因此自动获得企业级承诺。企业真正需要确认的是：

• 谁负责发布安全修复；
• 大版本升级有没有明确路径；
• 扩展与数据库内核、操作系统和备份工具是否兼容；
• 出现故障时谁响应，是否有明确的支持边界；
• 许可证和二次分发方式是否符合企业要求。

我之前写过一篇 把 PostgreSQL 比作“毛坯房”的文章，重点是讨论开源底座怎样经过能力补齐、运维工具和服务体系，变成企业愿意长期使用的产品。这篇新文章和它有共同的判断，但观察角度不同： 那篇讨论“企业级产品还要补什么”，这篇先追问“开发者榜单到底证明了什么”。

六、原生 PostgreSQL 和企业级交付不是一回事

“原生 PostgreSQL 没有面向企业级场景”这句话，如果理解成“PG 完全不能跑企业生产”，就说得太绝对了。现实里有很多企业长期运行 PostgreSQL，也有云托管服务和商业发行版在生产环境中提供支持。

更准确的说法是： 原生 PostgreSQL 是具备大量企业生产能力的通用数据库内核，但它本身不等于一套完整的企业数据库交付方案。

原生项目提供了事务一致性、WAL、权限、复制、备份相关机制和扩展接口等能力；企业还要把这些能力组合成一套能长期运行的系统。高可用和自动切换、备份恢复演练、异地灾备、监控告警、连接池、安全审计、扩展生命周期、大版本升级、容量规划、变更流程、7×24 小时支持和责任边界，都需要额外设计、验证和维护。

图 5：企业级不是某一个按钮，而是一组长期运行的工程和责任。

这也是我想表达的“落地需要付出很多”： 成本主要低在第一次启动，长期成本则集中在稳定运行、治理、升级、支持和责任承接上。

企业可以选择自建原生 PostgreSQL，也可以使用云托管或商业支持服务。后两者不是让这些工作消失，而是把其中一部分工作交给服务商，并用服务费用、平台边界和合同责任来交换。无论采用哪一种方式，生产环境都要有人对最终结果负责。

七、以后看到数据库榜单，我会先问这几句

榜单不是没用。它能告诉我们开发者正在接触什么、愿意继续用什么，能够帮助判断学习成本、工具生态和人才供给的变化。

只是每次看到“第一”，我会先把下面几件事问清楚：

1. 题目问的是“用过”、“做过大量开发”、“想继续用”，还是“生产使用”？
2. 分母是全部受访者，还是只回答了某一题的人？
3. 是单选还是多选？各项比例能不能相加？
4. 样本来自随机抽样，还是来自某个社区的自愿参与者？
5. 统计单位是开发者、企业、实例、容量、交易量，还是软件收入？
6. 排名有没有涉及高可用、灾备、审计、支持和业务关键性？

图 6：先把榜单的尺子看清楚，再决定它能量出什么。

这几句问完，PostgreSQL 的 57.9% 仍然很有价值：它说明 PG 在开发者侧的覆盖度已经很高。但如果要谈企业生产，还得补上另一套数据：组织采用情况、实例和集群规模、业务类型、数据与交易量、SLA、灾备目标，以及长期支持团队。

总结

PG 又第一了，这个第一值得高兴，也值得把脚注看完。

57.9% 说明 PostgreSQL 在 Stack Overflow 这批受访者中拥有很强的开发者覆盖度，不代表全球生产数据库占比。数据库问题只有 12,061 份回答，而且是可选、多选的社区调查；样本看起来不少，却不足以回答企业生产规模这个问题。

PostgreSQL 的优势确实在于开发者容易开始、扩展方便、验证路径短；企业级落地的难点则在长期运行、治理、升级、支持和责任承接。社区驱动不等于不专业，原生内核也不等于完整交付方案。

看榜单可以判断开发者生态的风向，做生产选型还要把业务关键性、故障后果和谁来负责放进同一张表里。排名第一的数据库，到了生产现场仍然要接受这些问题的追问。

老规矩，知道写了些啥。