天下大势
今天下三分，然Oracle ｜ MySQL ｜ SQL Server 疲敝，日薄西山。PostgreSQL紧随其后，如日中天。Top4的数据库中，前三名都在走下坡路，唯有PG增长势头不减，此消彼长，前途无量。
在唯二两个头部开源关系型数据库 MySQL & PgSQL 中，MySQL (2nd) 虽占上风，但其生态位却在逐渐被PostgreSQL (4th) 和非关系型的文档数据库MongoDB (5th) 抢占。按照现在的势头，用不了几年，PostgreSQL的流行度即将跻身前三，与Oracle、MySQL分庭抗礼。
竞争关系
关系型数据库的生态位高度重叠，其关系可近似视为零和博弈。与PostgreSQL形成直接竞争关系的，就是Oracle与MySQL。
Oracle稳坐数据库流行度排名头把交椅，作为老牌商业数据库，有着深厚的历史技术积淀。功能丰富，支持完善，广受不差钱的企业组织喜爱。不过授权费用昂贵，且以讼棍行径成为知名的业界毒瘤。SQL Server排名第三，属于相对独立的微软生态，而性质上与Oracle类似，都属于商业数据库。商业数据库整体受开源数据库冲击，流行度处于缓慢衰减的状态。
MySQL流行度位居第二，但树大招风，处于前有狼后有虎，上有野爹下有逆子的不利境地：在严谨的事务处理和数据分析上，MySQL被同为开源关系型数据库的PgSQL甩开几条街；而在糙猛快的敏捷方法论上，MySQL又不如新兴的NoSQL产品。同时，MySQL上有Oracle父爱如山，中有MariaDB兄弟分家，下有诸如TiDB/OB之类协议兼容的NewSQL逆子造反，因而也止步不前。
唯有PostgreSQL迎头赶上，保持着近乎指数增长的势头。如果说几年前PG的势还是Potential，那么现在Potential已经开始兑现为Impact，开始对竞争对手构成强力挑战。
而在这场你死我活的斗争中，PostgreSQL占据了三个“势”：
- 开源软件普及发展，蚕食商业软件市场
在去IOE与开源浪潮的大背景下，凭借开源生态对商业软件（Oracle）形成压制。 - 满足用户日益增长的数据处理功能需求
凭借地理空间数据的事实标准PostGIS处理立于不败之地，凭借对标Oracle的极为丰富的功能，对MySQL形成技术压制。 - 市场份额均值回归的势
国内PG市场份额因历史原因，远低于世界平均水平，本身蕴含着巨大势能。
Oracle作为老牌商业软件，才毋庸质疑，同时作为业界毒瘤，“德”也不必多说，故曰：“有才无德”。MySQL有开源之功德，但它一来采用了GPL协议，比起使用无私宽松BSD协议的PgSQL还是差不少意思，二来认贼作父，被Oracle收购，三来才疏学浅，功能简陋，故曰“才浅德薄”。
德不配位，必有灾殃。唯有PostgreSQL，既占据了开源崛起之天时，又把握住功能强劲之地利，还有着宽松BSD协议之人和。正所谓：藏器于身，因时而动。不鸣则已，一鸣惊人。德才兼备，攻守之势易矣！
德才兼备
PostgreSQL的德
PG的“德”在于开源。什么叫“德”，合乎于“道”的表现就是德。而这条“道”就是开源。
PG本身就是祖师爷级开源软件，是开源世界中的一颗明珠，是全世界开发者群策群力的成功典范。而且更重要的是它采用无私的类BSD协议：除了打着PG的名号招摇撞骗外，基本可以说是百无禁忌：比如换皮改造为国产数据库出售。PG可谓无数数据库厂商们的衣食父母。子孙满堂，活人无数，功德无量。
PostgreSQL的才
PG的“才”在于一专多长。PostgreSQL是一专多长的全栈数据库，天生就是HTAP，超融合数据库，一个打十个。单一组件便能满足绝大多数中小型企业的各类数据需求：OLTP，OLAP，时序数据库，空间GIS，全文检索，JSON/XML，图数据库，缓存，等等等等。
在一个很可观的规模内，PostgreSQL都可以胜任多面手的角色：一个组件当多种组件使。而单一数据组件选型可以极大地削减项目额外复杂度，这意味着能节省很多成本。让十个人才能搞定的事，变成一个人就能搞定的事。 如果真有那么一样技术可以满足你所有的需求，那么使用该技术就是最佳选择，而不是试图用多个组件来重新实现它。
开源之德
Once open source gets good enough, competing with it would be insane.
—— Larry Ellison, Oracle CEO
开源是有大功德的。互联网的历史就是开源软件的历史，IT行业之所以有今天的繁荣，人们能享受到如此多免费的信息服务，核心原因之一就是开源软件。开源是一种真正成功的，由开发者构成的 communism（译作 社区主义 更为贴切 ）：软件这种IT业的核心生产资料变为全世界开发者公有，人人为我，我为人人。
一个开源程序员工作时，其劳动背后可能蕴含有数以万计的顶尖开发者的智慧结晶。互联网程序员身价贵，从某种程度上来讲是因为：其实程序员不是一个普通工人，而是一个指挥软件和机器来干活的包工头。 程序员自己就是核心生产资料，而服务器很容易取得（相比其他行业的科研设备与实验环境），大部分软件来自公有社区，所以一个或几个高级的软件工程师便可以很轻松的利用开源生态快速解决领域问题。
通过开源，所有社区开发者形成合力，极大降低了重复造轮子的内耗。使得整个行业的技术水平以匪夷所思的速度向前迈进。开源的势头就像滚雪球，时至今日已经势不可挡。基本上除了一些特殊场景和路径依赖，在软件开发（特别是基础软件）中闭门造车，搞自力更生几乎成了一个大笑话。
所以说，搞数据库也好，做软件也罢，搞技术就要搞开源的技术，闭源的东西生命力太弱，没意思。开源之德，也是PgSQL与MySQL这样的开源数据库对Oracle这样的商业闭源软件的最大底气所在。
生态之争
开源的核心就在于生态（ECO），每一个开源技术都有自己的小生态。所谓生态就是各种主体及其环境通过密集相互作用构成的一个系统，而开源软件的生态模式大致可以描述为由以下三个步骤组成的正反馈循环：
- 开源软件开发者给开源软件做贡献
- 开源软件本身免费，吸引更多用户
- 用户使用开源软件，产生需求，创造更多开源软件相关岗位
开源生态的繁荣有赖于这个闭环，而生态系统的规模（用户/开发者数量）与复杂度（用户/开发者质量）直接决定了这个软件的生命力，所以每一个开源软件都有天命去扩大自己的规模。而软件的规模通常取决于软件所占据的生态位，如果不同的软件的生态位重叠，就会发生竞争。在开源关系型数据库的生态位中，PgSQL与MySQL就是最直接的竞争者。
流行 vs 先进
一个成功的技术，现实的优先级必须高于公关，你可以糊弄别人，但糊弄不了自然规律。
——罗杰斯委员会报告（1986）
MySQL的口号是“世界上最流行的开源关系型数据库”，而PostgreSQL的Slogan则是“世界上最先进的开源关系型数据库”，一看这就是一对老冤家了。这两个口号很好的反映出了两者的形象特质：PostgreSQL是功能丰富，高大上的严谨的学院派数据库；MySQL是轻简粗陋，糙猛快的“工程派”数据库。
MySQL的用户集中于互联网公司，而互联网公司的特点就是糙猛快。 糙 说的是互联网公司业务场景相对简单，CRUD居多；数据重要性通常也不高，不像传统行业（例如银行）那样在意数据的一致性、完整性、正确性；可用性优先，相比停服务更能容忍数据丢乱错，而一些行业用户宁可停止服务也不能让账目出错。 猛 说的则是互联网行业数据量大，所以它们需要的就是水泥槽罐车，而不是超跑和航天飞机。 快 说的则是互联网行业需求变化多端，出活周期短，要求响应时间快，大量需求的就是开箱即用的软件全家桶（如LAMP）和简单培训一下就能干活的CRUD Boy。于是乎，糙猛快的互联网公司和糙猛快的MySQL一拍即合。
而PostgreSQL的用户则更偏向于传统行业，传统行业之所以称为传统行业，就是因为它们已经走过了野蛮生长的阶段，有着成熟的业务模型与深厚的底蕴积淀。它们需要的是正确的结果，稳定的表现，丰富的功能，对数据进行分析加工提炼的能力。所以在这些行业中往往是Oracle、SQL Server、PostgreSQL的天下。特别是在地理相关的场景中，PostgreSQL更是有着不可替代的地位。当然随着时代变迁，不少互联网公司的业务也开始成熟沉淀，一只脚迈入“传统行业”了，很多脱离了糙猛快低级循环阶段的互联网公司，也开始将目光投向了PostgreSQL 。
谁更正确？
最了解一个人的，往往是他的竞争对手：PostgreSQL与MySQL的口号都很精准地戳中了对手的痛点。PgSQL“最先进”的潜台词就是MySQL太落后，而MySQL”最流行“就是说PgSQL不流行。用户少但先进，用户多但落后。哪一个更”好“？这种价值判断的问题很难回答，每个人都有自己的看法。
但我认为，时间站在 先进 的一边：因为先进与落后是技术的核心度量，是因，而流行与否则是果；流行不流行是内因（技术是否先进）和外因（历史路径依赖）共同对时间积分的结果。当下的因会反映为未来的果：流行的东西会因为落后而过气，而先进的东西会因为先进而流行。
很多流行的东西都是垃圾，但流行并不一定代表着落后。如果只是缺少一些功能，MySQL还不至于被称为“落后”。问题在于，MySQL已经糙到连事务这种关系型数据库的基本功能都有缺陷：那就不是落不落后的问题，而是合不合格的问题了。
ACID
一些作者声称，支持通用的两阶段提交代价太大，会带来性能与可用性的问题。让程序员来处理过度使用事务导致的性能问题，总比缺少事务编程好得多。
——James Corbett等，Spanner：Google的全球分布式数据库（2012）
MySQL的哲学可称之为：“好死不如赖活着” ，或 “我死后哪管洪水滔天”。 其“可用性”体现在各种“容错”上，例如，让呆瓜程序员写出的错误的SQL查询也能跑起来：最离谱的例子莫过于MySQL竟然允许部分成功的事务提交，这就违背了关系型数据库的基本约束：原子性与数据一致性。
这里在一个事务中插入了两条记录，第一条成功插入，而第二条因为主键冲突违反约束而失败。根据事务原子性的定义，整个事务要么整个成功，要么整个失败（最终一条都没有插入）。结果MySQL的默认表现竟然是允许部分成功的事务提交（写入一条，丢弃一条），也就是丧失了原子性。 没有原子性就没有一致性，如果这是一笔转账事务（一条扣款，一条打款），那这里的帐就做不平了。
滑稽的是，还有一些MySQL用户将其称为“特性”，说这体现了MySQL的容错性。实际上，此类“特殊容错”需求在SQL标准中完全可以通过SAVEPOINT机制实现。PgSQL对此的实现就堪称典范，psql客户端允许通过ON_ERROR_ROLLBACK选项，隐式地在每条语句后创建SAVEPOINT，并在语句失败后自动ROLLBACK TO SAVEPOINT，以标准SQL的方式，以客户端可选项的形式，在不破坏事物ACID的情况下，同样实现这种看上去便利实则苟且的功能。相比之下，MySQL的这种所谓“特性”是以直接在服务端默认牺牲事务ACID为代价的（这意味着用户使用JDBC等驱动的应用也同样受此问题影响）。
如果是互联网业务，注册个新用户丢个头像、丢个评论可能不是什么大事。数据那么多，丢几条，错几条又算个什么？别说是数据，业务本身很可能都处于朝不保夕的状态，所以糙又如何？万一业务发达了，前人拉的屎反正也有后人来擦。所以一些互联网公司通常并不在乎这些。
PostgreSQL所谓“严格的约束与语法“可能对新人来说“不近人情”，例如，一批数据中如果有几条脏数据，MySQL可能会照单全收，而PG则会严格拒绝。苟且妥协尽管看上去很省事，但在其他地方埋下了雷：因为逻辑炸弹深夜加班排查擦屁股的工程师，和不得不天天清洗脏数据的数据分析师一定对此怨念很深。
从长期看，要想成功，做正确的事最重要。
MySQL的流行度并没有和PgSQL相差太远，然而其功能比起PostgreSQL和Oracle却是差距不小。Oracle与PostgreSQL算诞生于同一时期，再怎么斗，立场与阵营不同，也有点惺惺相惜的老对手的意思：都是扎实修炼了半个世纪内功，厚积薄发的老法师。而MySQL就像心浮气躁耍刀弄枪的二十来岁毛头小伙子，凭着一把蛮力，借着互联网野蛮生长的黄金二十年趁势而起，占山为王。
时代所赋予的红利，也会随时代过去而退潮。在这个变革的时代中，没有先进的功能打底，“流行”也恐怕也难以长久。
发展前景
从个人发展的角度看，很多程序员学习一门技术都是为了提高自己的竞争力（从而更好地占坑赚钱）。PostgreSQL是各种关系型数据库中性价比最高的选择：它不仅可以用来做传统的CRUD OLTP业务，数据分析也是它的拿手好戏，各种特色功能更是提供了切入诸多行业的契机：基于PostGIS的地理时空数据处理分析，基于Timescale的时序金融物联网数据处理分析，基于Pipeline存储过程触发器的流式处理，基于倒排索引全文检索的搜索引擎，使用FDW统一对接各式外部数据源。对于海量数据处理，更是可以平滑升级至分布式版本：Citus/GreenPlum/MatrixDB等。可以说，它是真正一专多长的全栈数据库。它可以实现的功能，要比普通的纯OLTP数据库要丰富得多，为CRUD Boy提供了一条转型与深入的进阶道路。
从企业用户的角度来看，PostgreSQL在一个很可观的规模内都可以独立扮演多面手的角色，一个组件当多种组件使。而单一数据组件选型可以极大地削减项目额外复杂度，这意味着能节省很多成本。它让十个人才能搞定的事，变成一个人就能搞定的事。 当然这不是说PG要一个打十个，把其他数据库的饭碗都卷翻，专业组件在专业领域的实力是毋庸置疑的。但切莫忘记，为了不需要的规模而设计是白费功夫，实际上这属于过早优化的一种形式。
以探探为例，在250WTPS与200TB数据的量级下，单一PostgreSQL选型 依然能稳如老狗地支撑业务。能在很可观的规模内做到一专多长，除了本职的OLTP，PG还在很长一段时间中兼任了缓存、OLAP、批处理，甚至消息队列的角色。神龟虽寿，犹有竟时，最终这些兼职功能还是逐渐分拆出去由专用组件负责，但那已经是近千万日活时的事了。
从商业生态的角度看，PostgreSQL也有巨大的优势。一来PG技术先进，原生PG对Oracle的功能就做到了八九成的兼容性，EDB更是有96% Oracle兼容的专业PG发行版，因此可以看作是开源版的Oracle。是唯一能对Oracle构成直接威胁的开源关系型数据库。在抢占去O腾退出的市场中，PostgreSQL及其衍生版本的技术优势是压倒性的。二来PG协议友善，采用了宽松的类BSD协议。各种数据库厂商，云厂商出品的“自研/国产数据库”，以及很多“云数据库”大多都是基于PostgreSQL改造的。例如最近HW基于PostgreSQL搞openGaussDB就是一个很明智的选择。PG的协议确实允许这样做，而且这样做也确实让PostgreSQL的生态更加繁荣壮大了。卖PostgreSQL衍生版是一个很成熟的市场：传统企业不差钱且愿意为此付费买单。开源天才之火有商业利益之油浇灌，因而源源不断地释放出旺盛的生命力。
vs MySQL
作为老对手，MySQL的处境就有些尴尬了。
从个人职业发展上来看，MySQL基本只能用来CRUD。虽然说学好增删改查当一个合格的码农是没问题的，然而谁又愿意一直当“数据矿工”呢？数据分析才是数据产业链上的暴利肥差。以MySQL孱弱的分析能力，很难支持CURD程序员升级转型发展。
从供需关系来看，MySQL培训已经烂大街了，卷成了一片血海。而PostgreSQL的市场需求摆在那里，却面临供不应求的状况（不过现在已经有大量PG培训机构冒了出来）。MySQL的人确实比PgSQL的人好招，这是不假的，但反过来看，供不应求方才体现稀缺性，人太多，技能自然也就贬值了。
从企业用户的角度来看，MySQL就是专用于OLTP的单一功能组件，往往需要ES, Redis, Mongo，CK等其他组件一起配合才能满足完整的数据存储需求，而PG基本就不会有这个问题。此外，MySQL和PgSQL都是开源数据库，都“免费”。既然都免费，免费的“开源Oracle”，和免费的MySQL，哪个更香呢？
从商业生态来看，MySQL面临的最大问题是 叫好不叫座。叫好当然是因为越流行则声音越大，更何况MySQL的主要用户——互联网企业本身就占据了话语权高地。但不叫座也是因为互联网公司：互联网公司对于数据库这类软件付费的意愿是极弱的：因为怎么算都是招几个MySQL DBA自己搭开源的更合算。
从衍生产品来看，因为MySQL的GPL协议要求衍生软件也要开源，软件厂商基于MySQL研发的动机也不强，基本都是采用 兼容“MySQL” 协议来分MySQL的市场蛋糕，而不是基于MySQL的代码进行开发与回馈，大孝子满堂，生态健康程度也是堪忧。
而说到底，MySQL最大的问题，就是它的生态位越来越狭窄。论严谨的事务处理与数据分析，PostgreSQL甩开它几条街；论糙猛快出原型，NoSQL全家桶又要比MySQL方便太多。论商业发财，上面有Oracle干爹压着；论开源生态，又不断出现兼容MySQL的新生代产品来尝试篡位。MySQL处在了吃老本的危险境地，只是凭籍历史积分存量勉强维持着现状，但时间是否会站在MySQL这一边，我们只能拭目以待了。
vs NewSQL
最近市场上也出现了一些亮眼的NewSQL产品：如TiDB，Cockroachdb，Yugabytedb等等。何如？我认为它们都是很好的产品，有一些不错的技术亮点，都是对开源生态的贡献。但是它们可能同样面临叫好不叫座的困局。
NewSQL的重要特征是：主打“分布式”的概念，通过“分布式”解决水平扩展性与容灾高可用两个问题，但会因为分布式的内在局限性而牺牲很多功能（例如各种复杂JOIN），只能支持简单有限的查询种类。在高可用/容灾方面，分布式数据库与主从复制并没有质的区别，因此其主要特征可以概括为“以质换量”。
然而，对很多企业而言，牺牲功能换取伸缩性很可能是一个伪需求或弱需求。OLTP数据库是一种工作记忆，极少有业务能超出单机主从的极限（参考值：单集群写入上限十几万TPS，读取几十万～百万QPS，数据量几TB～百TB），更何况还有分库分表的传统优化方式。在我所接触到的大量用户中，超出单机PG处理能力的业务场景屈指可数。一个中型互联网公司或银行的全部TP数据约在百TB量级。而绝大多数企业的全部数据，终其生命周期也超不过这个瓶颈。至于性能就更不重要了：过早优化是万恶之源，很多企业的DB性能余量足够让他们把所有业务逻辑用存储过程编写，然后快乐地跑在数据库里面。
NewSQL的祖师爷Google Spanner就是为了解决海量数据扩展性的问题，但又有多少企业能有Google的业务数据量？恐怕还是只有典型的互联网公司，或者某些大企业的极少部分业务场景会有这种量级的数据存储需求。因此和MySQL一样，NewSQL的问题就回到了谁来买单这个根本问题上。恐怕到最后，还是只能由投资人和国资委来接盘吧？
但最起码，NewSQL的这种尝试始终是值得赞扬的。
vs 云数据库
“我想直率地说：多年来，我们就像个傻子一样，他们拿着我们开发的东西大赚了一笔”。
—— Ofer Bengal ， Redis Labs 首席执行官
另一个值得关注的“竞争者”是所谓云数据库，包括两种：一种是云上托管的开源数据库，如 RDS for PostgreSQL；另一种则是自研的“新一代云数据库”。
前者主要的问题就是“云厂商吸血”。如果云厂商售卖开源软件，实际上会导致开源软件的相关岗位和利润向云厂商集中。而云厂商是否允许自己的程序员给开源项目做贡献，做到什么程度，其实是很难说的。负责任的大厂通常会回馈社区，回馈生态，但这取决于他们的自觉。开源软件社区还是应当将命运掌握在自己手中，防止云厂商做大形成垄断。由更多分散用户团体组成的生态系统，比少数巨头把持垄断的生态系统要有着更丰富的多样性与更持续的发展潜力。
Gartner称，2022年75%的数据库将部署至云平台，这个牛皮吹的太大了。（但也有圆的办法，毕竟用一台云虚拟机就可以轻松创建几亿个sqlite文件数据库，这算不算？） 云计算解决不了一个根本性的问题 —— 信任。实际上在商业活动中，技术牛不牛逼是次要的因素，Trust才是关键所在。数据是很多企业的生命线，而云厂商并非真正的中立第三方，谁能保证自己的数据不会被其偷窥，盗窃，泄漏，乃至于直接被卡脖子关停服务呢？（例如各路云厂商锤死Parler）
另一个问题在于成本：以目前云厂商的定价策略，云数据库只有在小微规模下有优势。例如一台Dell R740 64C|400 GB Mem | 3TB PCI-E SSD 的高配机型，四年综合成本撑死了也就十几万块钱。然而我能找到最大的规格的RDS（ 32 C | 128 GB Mem，差很多），一年的价格就这个数了。只要数据量与节点数稍微上一点规模，招个DBA自建就合算太多了。当然，这也可能是在互联网公司的立场上站着说话不腰疼，云计算相比传统行业的黑灰色采购，也许还是便宜不少的。
云数据库的主要优势还是在于管控，说白了就是用起来方便，点点鼠标。日常运维功能已经覆盖的比较全面，也有一些基础的监控支持。下限摆在那里：如果找不到靠谱的数据库人才，用云数据库起码不至于出太多幺蛾子。 不过这些管控软件虽好，基本都是闭源的，而且与供应商深度绑定。
如果你想找一个开源的PostgreSQL一条龙解决方案，不妨试试 Pigsty。
后一种云数据库以AWS Aurora为代表，也包括一系列类似产品如阿里云PolarDB，腾讯云CynosDB。基本都是采用PostgreSQL与MySQL作为Base和协议层，基于云基础设施（共享存储，S3，RDMA）进行定制化，对扩容速度与性能进行了优化。这类产品在技术上肯定是有新颖性和创造性的。但仍然免不了来自甲方的灵魂拷问：这类产品比起直接使用原生PostgreSQL的收益到底在哪里呢？立竿见影的好处是，集群扩容会快很多，从几小时提升至几分钟，但也仅此而已；相比高昂的费用与供应商锁定的问题，实在难以称得上有吸引力。
总的来说，云数据库对原生PostgreSQL构成有限威胁，但云厂商总体来说还是开源软件生态的一份子，对社区是有贡献的，不能苛责太多，赚钱嘛，不磕碜。大家都有钱赚了，才有余力去搞公益，对不对？
PG的问题
当然PgSQL有没有自己的问题？当然也有 —— 流行度。
流行度关乎着着用户规模，信任水平，成熟案例数量，有效需求反馈量，开发者数量等等。更重要的是，规模效应会产生滚雪球的效果。更流行，意味着更多的用户与需求，更多的工作岗位与开发者，而这些又将进一步推动软件的流行，构成一个正反馈。
尽管目前PgSQL还不如MySQL流行，想找到高水平的人才也更为困难。但PostgreSQL的雪球已经开始滚起来了，而且来势汹汹。按当前的流行度发展趋势，也许用不了几年，就能超过MySQL了。
我并不担心PgSQL的前景与未来，但作为PostgreSQL社区的一员，我不希望在这波澜壮阔的征程中仅仅当一个旁观者，而是要知行合一，做出自己力所能及的贡献。所以，我开发了一个开源软件 Pigsty ，这是一个免费的生产级PostgreSQL解决方案，旨在把使用PostgreSQL的门槛从天花板压到地板上：一条命令完成安装，一键拉起高可用PG集群；让大规模数据库集群的部署实施，管理运维，设计使用这种门槛颇高的事情，成为普通研发运维人员几分钟就能搞定的事情。
Pigsty将集群部署，扩容缩容，主从复制，故障切换，流量代理，连接池，服务发现，访问控制，监控系统，告警系统，日志采集等生产级成熟解决方案封装为发行版，一次性解决在生产环境与各类场景下使用世界上最先进的开源关系型数据库 —— PostgreSQL时会遇到的问题，真正做到开箱即用。
用好数据库，用好 数据库。拥有自己的数据库私有云，从未如此简单！
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/310828.html