为什么PostgreSQL是最成功的数据库?

微信公众号原文

当我们说一个数据库"成功"时,到底在说什么?是指功能性能易用性,还是成本生态复杂度?评价指标有很多,但这件事最终还得由用户来定夺。

数据库的用户是开发者,而开发者的意愿、喜好、选择又如何?StackOverflow 连续六年,向来自180个国家的七万多开发者问了这三个问题。

总览这六年的调研结果,不难看出在2022年,PostgreSQL 已经同时在这三项上登顶夺冠,成了字面意义上 “最成功的数据库”:

  • PostgreSQL 成为 专业开发者最常使用的数据库!(Used)
  • PostgreSQL 成为 开发者最为喜爱的数据库!(Loved)
  • PostgreSQL 成为开发者最想要用的数据库!(Wanted)

流行度反映当年势能,需求度预示来年动能,喜爱度代表长期潜能。时与势都站在 PostgreSQL 一侧,让我们来看一看更具体的数据与结果。


最流行

PostgreSQL —— 专业开发者中最流行的数据库!(Used)

第一项调研,是关于开发者目前使用着什么样的数据库,即,流行度

过去几年,MySQL一直霸占着数据库流行榜的榜首,很符合其 ”世界上最流行的开源关系型数据库“ 这一口号。不过这一次,”最流行“的桂冠恐怕要让给 PostgreSQL 了。

专业开发者中,PostgreSQL 以 46.5% 的使用率第一次超过 MySQL 位居第一,而 MySQL 以 45.7% 的使用率降至第二名。 同为泛用性最好的开源关系型数据库,排名第一第二的 PGSQL 与 MySQL ,与其他的数据库远远拉开了距离。

TOP 9 数据库流行度演变(2017-2022)

PGSQL 与 MySQL 的流行度差别并不大。值得一提的是,在见习开发者群体中,MySQL 仍然占据显著使用率优势(58.4%),如果算上见习开发者,MySQL 甚至仍然保有 3.3% 的微弱整体领先优势。

但从下图中不难看出,PostgreSQL 有显著的增长动能,而其他数据库,特别是 MySQL、 SQL Server、Oracle 的使用率则在最近几年持续衰退。随着时间的推移,PostgreSQL 的领先优势将进一步拉大。

四大关系型数据库流行度对比

流行度反映的是当下数据库的规模势能,而喜爱度反映的是未来数据库的增长潜能。


最喜爱

PostgreSQL —— 开发者最为喜爱的数据库!(Loved)

第二个问题是关于开发者喜爱什么数据库,讨厌什么数据库。在此项调研中,PostgreSQL与Redis一骑绝尘,以70%+ 的喜爱率高居榜首,显著甩开其他数据库。

在过去几年,Redis一直是用户最喜欢的数据库。在 2022 年,形势发生了变化,PostgreSQL 第一次超过 Redis,成为最受开发者喜爱的数据库。 Redis是简单易用的数据结构缓存服务器,经常会与关系型数据库搭配使用,广受开发者喜爱。不过开发者明显更爱功能强大得多的 PostgreSQL 多一丢丢。

相比之下 MySQL 与 Oracle 的表现就比较拉胯了。喜欢和讨厌 MySQL 的人基本各占一半;而只有35%的用户喜欢 Oracle ,这也意味着近 2/3 的开发者反感 Oracle 。

TOP 9 数据库喜爱度演变(2017-2022)

从逻辑上讲,用户的喜爱将导致软件的流行,用户的厌恶将导致软件过气。 我们可以参照 净推荐指数(NPS,又称口碑,推荐者%-贬损者%)的构造方式, 设计一个净喜爱指数 NLS:即 喜爱人群% - 厌恶人群%, 而数据库流行度的导数应当与 NLS 呈现正相关性 。

数据很好的印证了这一点: PGSQL 有着全场最高的 NLS: 44% ,对应着最高的流行度增长率 每年 460个基点。 MySQL 的口碑刚好落在褒贬线上方 (2.3%),流行度平均增速为36个基点; 而 Oracle 的口碑则为负的 29%,对应平均每年44个基点的使用率负增长。 当然在这份榜单上, Oracle 只是倒数第三惨的,最不受人待见的是 IBM DB2 : 1/4的人喜欢,3/4的人讨厌,NLS = -48% ,对应46个基点的年平均衰退。

当然,并不是所有潜能,都可以转换为实打实的动能。 用户的喜爱并不一定会付诸行动,而这就是第三项调研所要回答的问题。


最想要

PostgreSQL —— 开发者 最想使用的数据库!(Wanted)

“在过去的一年中,你在哪些数据库环境中进行了大量开发工作?在未来一年,你想在哪些数据库环境中工作? ”

对于这个问题前半段的回答,引出了”最流行“数据库的调研结果;而后半段,则给出了”最想要“这个问题的答案。 如果说用户的喜爱代表的是未来增长的潜能,那么用户的需求(想要,Want)就代表了下一年实打实的增长动能。

在今年的调研中, PostgreSQL 毫不客气的挤开 MongoDB ,占据了开发者最想使用数据库的宝座。 高达 19% 的受访者表示,下一年中想要使用 PostgreSQL 环境进行开发。 紧随其后的是 MongoDB (17%) 与 Redis (14%),这三种数据库的需求程度与其他数据库显著拉开了一个台阶。

此前, MongoDB 一直占据”最想要“数据库榜首,但最近开始出现过气乏力的态势。 原因是多方面的:例如,MongoDB 本身也受到了 PostgreSQL 的冲击。 PostgreSQL 本身就包含了完整的 JSON 特性,可直接用作文档数据库,更有类似 FerretDB (原名 MangoDB)的项目可以直接在 PG 上对外提供 MongoDB 的 API。

MongoDB 与 Redis 都是 NoSQL 运动的主力军。但与 MongoDB 不同,Redis的需求在不断增长。PostgreSQL 与 Redis,分别作为 SQL 与 NoSQL 的领军者,保持着旺盛的需求与高速的增长,前途无量。


为什么?

PostgreSQL 在需求率, 使用率,喜爱率上都拔得头筹,天时地利人和齐备,动能势能潜能都有,足以称得起是最成功的数据库了。

但我们想知道的是,为什么 PostgreSQL 会如此成功 ?

其实,秘密就藏在它的 Slogan 里: ”世界上最先进开源 关系型数据库“。


关系型数据库

关系型数据库是如此的普及与重要,也许其他的数据库品类如键值,文档,搜索引擎,时序,图,向量加起来也比不上它的一个零头。以至于当大家谈起数据库时,如果没有特殊说明,默认隐指的就是”关系型数据库“。在它面前,没有其他数据库品类敢称自己为”主流“。

DB-Engine 为例,DB-Engine的排名标准包括搜索系统名称时的搜索引擎结果数,Google趋势,Stack Overflow讨论,Indeed 提及系统的工作机会,LinkedIn等专业网络中的个人资料数,Twitter等社交网络中的提及数等,可理解为数据库的“综合热度”。

数据库热度趋势:https://db-engines.com/en/ranking_trend

在 DB-Engine 的热度趋势图中我们可以看到一条鸿沟,前四名全都是 关系型数据库 ,加上排名第五的 MongoDB,与其他数据库在热度上拉开了 数量级上的差距。 我们只需要把关注点聚焦到这四种核心的关系型数据库 Oracle,MySQL,SQL Server,PostgreSQL 上即可。

关系型数据库的生态位高度重叠,其关系可以视作零和博弈。抛开微软生态关门自嗨相对独立的商业数据库 SQL Server不提。在关系型数据库世界里,上演的是一场三国演义。

Oracle有才无德,MySQL才浅德薄,唯有PostgreSQL德才兼备。

Oracle是老牌商业数据库,有着深厚的历史技术积淀,功能丰富,支持完善。稳坐数据库头把交椅,广受不差钱且需要背锅侠的企业喜爱。但Oracle费用昂贵,且以讼棍行径成为知名的业界毒瘤。Microsoft SQL Server性质与Oracle类似,都属于商业数据库。商业数据库整体受开源数据库冲击,处于缓慢衰退的状态。

MySQL流行度位居第二,但树大招风,处于前狼后虎,上有野爹下有逆子的不利境地:在严谨的事务处理和数据分析上,MySQL被同为开源生态位的PostgreSQL甩开几条街;而在糙猛快的敏捷方法论上,MySQL又不如新兴NoSQL好用;同时 MySQL 上有养父 Oracle 压制,中有兄弟 MariaDB 分家,下有诸如逆子 TiDB 等协议兼容NewSQL分羹,因此也在走下坡路。

作为老牌商业数据库,Oracle的毋庸质疑,但其作为业界毒瘤,“” ,亦不必多说,故曰:“有才无德”。MySQL 虽有开源之功德,奈何认贼作父;且才疏学浅,功能简陋,只能干干CRUD,故曰“才浅德薄”。唯有PostgreSQL,德才兼备,既占据了开源崛起之天时,又把握住功能先进之地利,还有着宽松BSD协议之人和。正所谓:藏器于身,因时而动。不鸣则已,一鸣惊人,一举夺冠!

而 PostgreSQL 德以致胜的秘密,就是 先进开源


开源之德

PG的“德”在于开源。祖师爷级的开源项目,全世界开发者群策群力的伟大成果。

协议友善BSD,生态繁荣扩展多。开枝散叶,子孙满堂,Oracle替代扛旗者

什么叫“德”,合乎于“道”的表现就是德。而这条“道”就是开源

PostgreSQL是历史悠久的祖师爷级开源项目,更是全世界开发者群策群力的典范成果。

生态繁荣,扩展丰富,开枝散叶,子孙满堂

很久很久以前,开发软件/信息服务需要使用非常昂贵的商业数据库软件:例如Oracle与SQL Server:单花在软件授权上的费用可能就有六七位数,加之相近的硬件成本与服务订阅成本。Oracle一个 CPU 核一年的软件授权费用便高达十几万,即使壕如阿里也吃不消要去IOE。以 PostgreSQL / MySQL 为代表的的开源数据库崛起,让用户有了一个新选择:软件不要钱。“不要钱” 的开源数据库可以让我们自由随意地使用数据库软件,而这一点深刻影响了行业的发展:从接近一万¥/ 核·月的商业数据库,到20块钱/核·月的纯硬件成本。数据库走入寻常企业中,让免费提供信息服务成为可能。

开源是有大功的。互联网的历史就是开源软件的历史,IT行业之所以有今天的繁荣,人们能享受到如此多的免费信息服务,核心原因之一就是开源软件。开源是一种真正成功的,以软件自由为目的,由开发者构成的 Communism(社区主义):软件这种IT业的核心生产资料变为全世界开发者公有,按需分配。开发者各尽所能,人人为我,我为人人。

一个开源程序员工作时,其劳动背后可能蕴含的是数以万计顶尖开发者的智慧结晶。程序员薪资高从原理上来说是因为,开发者本质上不是一个简单的工人,而是一个指挥软件和硬件干活的包工头。程序员自己就是核心生产资料;软件来自公有社区;服务器硬件更是唾手可得;因此一个或几个高级的软件工程师,就可以很轻松的利用开源生态快速解决领域问题。

通过开源,所有社区开发者形成合力,极大降低了重复造轮子的内耗。使得整个行业的技术水平以匪夷所思的速度向前迈进。开源的势头就像滚雪球,时至今日已经势不可挡。基本上除了一些特殊场景和路径依赖,软件开发中闭门造车搞自力更生几乎成了一个大笑话。

越是底层基础的软件,开源便越占优势。开源,也是 PostgreSQL 对阵 Oracle 的最大底气所在。

Oracle 先进,但 PostgreSQL 也不差。PostgreSQL 是 Oracle 兼容性最好的开源数据库,原生即支持 Oracle 85% 的功能,更有 96% 功能兼容的专业发行版。但更重要的是,Oracle价格高昂,而PG开源免费。压倒性的成本优势让PG拥有了巨大的生态位基础:它不一定要在功能先进性上超过 Oracle 才能成功 ,廉价9成正确已经足以干翻 Oracle 。

PostgreSQL 可以视作一个开源版的“Oracle”,是唯一能真正威胁到 Oracle 的数据库。作为 ”去O“ 抗旗者,PG 可谓子孙满堂, 36% 的 “国产数据库” 更是直接基于PG “开发”,养活了一大批 自主可控 的 数据库公司,可谓功德无量。更重要的是,PostgreSQL 社区并不反对这样的行为,BSD 协议允许这样做。这样开放的胸襟,是被Oracle收购的,使用GPL协议的MySQL所难以相比的。


先进之才

PG的“才”在于先进。一专多长的全栈数据库,一个打十个,天生就是 HTAP。

时空地理分布式,时序文档超融合,单一组件即可覆盖几乎所有数据库需求。

PG的“才”在于一专多长。PostgreSQL是一专多长的全栈数据库,天生就是HTAP,超融合数据库,一个打十个。基本单一组件便足以覆盖中小型企业绝大多数的数据库需求:OLTP,OLAP,时序数据库,空间GIS,全文检索,JSON/XML,图数据库,缓存,等等等等。

PostgreSQL是各种关系型数据库中性价比最高的选择:它不仅可以用来做传统的CRUD OLTP业务,数据分析更是它的拿手好戏。各种特色功能更是提供了切入多种行业以的契机:基于PostGIS的地理时空数据处理分析,基于Timescale的时序金融物联网数据处理分析,基于Pipeline存储过程触发器的流式处理,基于倒排索引全文检索的搜索引擎,FDW对接统一各式各样的外部数据源。可以说,PG是真正一专多长的全栈数据库,它可以实现的比单纯OLTP数据库要丰富得多的功能。

在一个很可观的规模内,PostgreSQL都可以独立扮演多面手的角色,一个组件当多种组件使。而单一数据组件选型可以极大地削减项目额外复杂度,这意味着能节省很多成本。它让十个人才能搞定的事,变成一个人就能搞定的事。 不是说PG要一个打十个把其他数据库的饭碗都掀翻:专业组件在专业领域的实力是毋庸置疑的。但切莫忘记,为了不需要的规模而设计是白费功夫,这属于过早优化的一种形式。如果真有那么一样技术可以满足你所有的需求,那么使用该技术就是最佳选择,而不是试图用多个组件来重新实现它。

以探探为例,在 250w TPS与 200TB 数据的量级下,单一PostgreSQL选型依然能稳定可靠地撑起业务。能在很可观的规模内做到一专多长,除了本职的OLTP,PG 还在相当长的时间里兼任了缓存,OLAP,批处理,甚至消息队列的角色。当然神龟虽寿,犹有竟时。最终这些兼职功能还是要逐渐分拆出去由专用组件负责,但那已经是近千万日活时的事了。

vs MySQL

PostgreSQL 的先进性有目共睹,这也是其对阵同为开源关系型数据库的老对手 —— MySQL 时,真正的核心竞争力。

MySQL的口号是“世界上最流行的开源关系型数据库”,它的核心特点是糙猛快,用户基本盘是互联网。互联网公司的典型特点是什么?追逐潮流糙猛快说的是互联网公司业务场景简单(CRUD居多);数据重要性不高,不像传统行业(例如银行)那样在意数据的一致性与正确性;可用性优先,相比停服务更能容忍数据丢乱错,而一些传统行业宁可停止服务也不能让账目出错。 说的则是互联网行业数据量大,它们需要的就是水泥槽罐车做海量CRUD,而不是高铁和载人飞船。 说的则是互联网行业需求变化多端,出活周期短,要求响应时间快,大量需求的就是开箱即用的软件全家桶(如LAMP)和简单培训就能上手干活的CRUD Boy。于是,糙猛快的互联网公司和糙猛快的MySQL一拍即合。

但时过境迁,PostgreSQL 进步神速,在”快“与”猛“上 MySQL 已经不占优了,现在能拿出手的只剩下”糙“了。举个例子,MySQL 的哲学可以称之为:“好死不如赖活着”,与 “我死后哪管洪水滔天”。 其“糙”体现在各种“容错”上,例如允许呆瓜程序员写出的错误的SQL也能跑起来。最离谱的例子就是MySQL竟然允许部分成功的事务提交,这就违背了关系型数据库的基本约束:原子性与数据一致性

图:MySQL默认竟然允许部分成功的事务提交

先进的因会反映为流行的果,流行的东西因为落后而过气,而先进的东西会因为先进变得流行。时代所赋予的红利,也会随时代过去而退潮。在这个变革的时代中,没有先进的功能打底,“流行”也也难以长久。在先进性上, PostgreSQL 丰富的功能已经甩开 MySQL 了几条街,而 MySQL 引以为豪的 ”流行度“ 也开始被 PostgreSQL 反超。

大势所趋,大局已定。正所谓:时来天地皆同力,运去英雄不自由。先进与开源,就是 PostgreSQL 最大的两样杀手锏。Oracle 先进, MySQL 开源,PostgreSQL 先进又开源。天时地利人和齐备,何愁大业不成?


展望未来

软件吞噬世界, 开源吞噬软件,而云吞噬开源。

看上去,数据库之争已经尘埃落定,一段时间内大概不会有其他数据库内核能威胁到 PostgreSQL 了。 但对 PostgreSQL 开源社区 真正的威胁,已经不再是其他数据库内核,而是软件使用范式的嬗变:云出现了。

最初,大家开发软件/信息服务需要使用昂贵的商业软件( Oracle,SQL Server,Unix)。而随着 Linux / PostgreSQL 这些开源软件的兴起,用户们有了新的选择。开源软件确实免费不要钱,但想用好开源软件,是一件门槛很高的事情,用户不得不雇佣开源软件专家来帮助自己用好开源软件。

当数据库上了规模,雇佣开源DBA自建始终是合算的,只是好DBA太稀缺了。

这便是开源的核心模式:开源软件开发者给开源软件做贡献;开源软件通过好用免费吸引大量用户;用户在使用开源软件时产生需求,创造更多开源软件相关就业岗位,创造更多的开源软件开发者。 这三步形成了一个正反馈循环:更多的开源贡献者让开源软件更好用,更省钱,从而吸引更多用户,并创造出更多的开源贡献者。开源生态的繁荣有赖于这个闭环,而公有云厂商的出现打破了这个循环。

公有云厂商将开源数据库套上壳,加上自己的硬件与管控软件,雇佣共享DBA提供支持,便成了云数据库。诚然这是一项很有价值的服务,但云厂商将开源软件放在自家的云平台售卖而鲜有回馈,实质上是一种通过“搭便车”吸血开源的行为。 这样的共享外包模式将导致开源软件的岗位向云厂商集中,最终形成少数巨头做大垄断,伤害到所有用户的软件自由。

世界已经被云改变了,闭源软件早已不是最重要的问题了。

在 2020 年,计算自由的敌人是云计算软件”。

这是 DDIA 作者 Martin Kleppmann 在其“本地优先软件”运动中提出的 宣言。云软件指的是运行在供应商服务器上的软件,例如:Google Docs、Trello、Slack、Figma、Notion 。以及最核心的云软件,云数据库

后云时代,开源社区如何应对云软件的挑战?Cloud Native 运动给出了答案。这是一场从公有云夺回软件自由的伟大运动,而数据库,则是其中的核心焦点。

Cloud Native 全景图,还缺少最后一块拼图:有状态的数据库!

这也是我们做 开箱即用的开源PostgreSQL 数据库发行版 —— Pigsty 想要解决的问题:做一个用户在本地即可使用的RDS服务,成为云数据库的开源替代!

Pigsty 带有开箱即用的 RDS / PaaS / SaaS 整合;一个无可比拟的PG监控系统与自动驾驶的高可用集群架构方案;一键安装部署,并提供 Database as Code 的易用体验;在体验比肩甚至超越云数据库的前提下,数据自主可控且成本减少 50% ~ 90%。我们希望它能极大降低 PostgreSQL 使用的门槛,让更多用户可以用 好数据库用好 数据库。

当然,限于篇幅,云数据库与后云时代的数据库未来,就是下一篇文章要介绍的故事了。

Last modified 2024-03-04: update labels (cacc77c)