今天在知乎上看到这样一个问题："postgresql也很强大，为何在国内，mysql成为主流，postgresql屈居二线呢？"
问题
我感觉postgresql非常强大，很多地方超过了mysql。
举几个例子： 1.丰富的数据类，支持数组、字典、json、序列号。 2.强大的审计函数 3.强大的索引，易于sql调优
postgresql在许多地方，有mysql无法比拟的优势。
但是在国内，许多公司的核心业务库，都是mysql，postgresql则屈居二线，作为审计类的数据库来使用。
为什么不让postgresql来扛大梁呢，而要用mysql，postgresql不合适么？
回答
整理了几个不错的回答，分享一下。
❝作者：大宽宽以下均为个人感觉，没做过统计，就当个参考吧。mysql和postgres的早期完全是两个极端。mysql更像是个“基本上满足关系数据库语法的大号KV”，对关系型数据库的高级功能支持的很不好。我入行时接触的MySQL 5.1和MyISAM存储引擎，不支持ACID，但有如下几点在当时的互联网公司看来是非常合适：互联网公司为了扩展，长期的经验是，仅仅把数据库当作是一个“存储”，而非存储+核心数据逻辑的计算节点。大量的计算都在业务服务器上进行，而业务服务器可以无限水平扩展，而无需担心有状态的数据迁移问题；因为没有提供很多高级功能和数据一致性的保障，mysql对于简单的sql支持的反而更加直接，在速度上有很大的优势；对于OLTP，完全不需要复杂的数据处理功能。简单的select ... from ... where id = xxx; insert into xxx；update xxx set xxx=xxx where id = xxxx是OLTP的主流功能。基于这些功能的ORM的出现大大的提高了生产效率；对于OLAP，尽管postgres查询分析功能很强，但是一般互联网公司的数据量实在太大，用postgres这种数据库根本无法处理。通常会用MapReduce，Hive，Pig等大数据处理工具来分析；多线程模型，天然对高并发支持良好。而pg一直是多进程模型。进程的创建会更慢，更耗内存。虽然有些pg的连接池方案，但是mysql在这方面“开箱即用”；postgres早期并不支持“逻辑复制”。物理复制意味着存储格式的细节完全暴露，不兼容的版本无法直接组成主从同步，于是无法做滚动升级。这就意味着在升级数据库时，必须停服，把整个集群升级后再恢复。而mysql从一开始就是逻辑复制（这其实是由于mysql一直是server和存储引擎分层的架构，逻辑复制发生在server层）。这个缺陷会让postgres的运营不受业务开发者的待见。谁也不希望自己的业务停服。反过来再看postgres的优点，会发现对于OLTP并没有太大的吸引力：丰富的数据类型 - 通常用处不大，常用类型足够了。如果有复杂类型，业务上自己序列化，存储成varchar就行。可以用json，PB，avro等。序列化反序列化都发生在业务服务器，更好维护和优化；强大的审计函数 - 互联网早期活下来是一切，审计并不是核心需求（通常需要严格审计的领域早就会用Oracle/MSql，不差钱）；强大的索引。postgres的自定义索引功能很强大。但是对于mysql，关键的几列有索引就够了，不需要复杂的高级索引。我承认早期mysql的查询优化器智商堪忧，但如果要改，一句explain，然后force index也就是了。对于开发人员简单直接。有一段时间LBS很流行，当时mongo很潮的直接支持了空间索引。当时大家纷纷的“NoSQL”，就更不会看postgres一眼。然后到了大概2015年，mysql 5.7也支持空间索引了。Posgres的MVCC实现牛逼不，牛。serial snapshot isolation是很强。但是到了需要变更数据严格一致的时候，select ... for update又不是不能用：）对于序列号，sequence是很好。但是互联网公司对于简单场景用auto increment。对于生产场景就直接用分布式序列号生成服务了。postgres的序列号产生器～偏鸡肋。Postgres的全文索引很强，但强的过ES？强的过专门定制的搜索引擎系统？要知道搜索业务最关键的是把“最匹配搜索人需要的搜索结果返回出来“，而不是仅仅”能搜到一堆不分主次但满足关键字匹配的结果“。因此早期mysql变成了事实上的互联网企业OLTP的事实标准。不管干啥业务，mysql都不可或缺。在行业里跳槽来跳槽去的程序员普遍对mysql也更熟悉。大量围绕mysql的商业服务都成为了行业主流。新一代分布式数据库，像TiDB为了吸引用户，首先要做的是“兼容mysql的语法”。再往后，mysql增加了更多“关系型数据库该有的”功能，比如完全支持ACID的innodb成为默认存储引擎，比如5.7的json原生支持，8.0的window function/CTE。而postgres也增加了更多的“互联网功能”。但是时机已经过去了。大家mysql跑着业务好好的。而切换数据库绝对不是仅仅像某些ORM标榜的换一个Dialect就行的。而是整个编程模型，性能表现，运维工具和流程都要有巨大的变化。如非必要，犯不着为了一个“most advanced"的标语去折腾，更不会为了数据库爱好者的情怀做伤害利益的事情。链接：https://www.zhihu.com/question/31955622/answer/1625152059
❝作者：聿明leslie
说说鄙人的见解，从技术而言，PG 功能丰富，SQL 支持得很完备，强大的数据类型，严谨的关系模型，很难从关系模型去找出PG 的不合理之处，多年的积累，连全文索引词库都非常丰富，据说对于一些简单的搜索，都可以摆脱搜索引擎了，优化器做得很好，在代价选择上PG 实现了基因算法，这一点连Oracle 也没有做到。
读过一部分PG 的代码和MySQL 的代码，对比起来，PG 的代码写得非常工整，注释也很细致，真的可以称得上code 教科书级别的工程，一定是一帮有情怀的coder 写出来的，对比起来，MySQL 就是一坨屎。
可是这个问题是一个工程性问题，就不要用这些方面来衡量一个工程问题！
历史总是时势造英雄，看看MySQL 火起来的那段时间，正是互联网爆发式增长的那几年，由于PG 丰富的功能，所以它显得太重了，多进程并发，再加上早期的存储做得不够好，太吃资源，在那个时代，内存和存储都是比较昂贵的资源.
早期的PG 性能也不太好，由于关系模型支持得很好，用起来会有诸多限制，学习成本会比较高，比起这些，MySQL 要轻量很多，到现在这也是它的一个优点，在互联网这个特定的场景中，大家为了追求快速迭代和拓展性，使用的SQL 功能不会太多，都够用，而PG 由于更严谨的SQL 关系模型，很多用法都限制得比较死，MySQL 却要灵活很多，你的劣势就出来了，这个让用户用起来很爽，但是对于兼容MySQL 的兼容实现者很痛苦，有些feature 在特定的场景中用起很便利，但是在通用的模型中却禁不起推敲，要不要兼容它呢？
但用户很难感知到这些，除非测试去乱试，一般人不会那么无聊，这就是工程上的权衡。很难说谁好谁坏。而用的人多了，相关的使用经验会汇总到社区，形成部署方案，工具等，这又是工程中的正反馈。
在江湖中，有几个身负各项绝技的大侠最后成了将军和皇帝的？
链接：
https://www.zhihu.com/question/31955622/answer/133904562
❝作者：flaneur
感觉是在几个互联网痛点的时间窗口没赶上，蛮可惜的。
之前 uber 有一篇文章：Why Uber Engineering Switched from Postgres to MySQL 里面提到的几个问题现在我猜应该有解决，但是时间点晚了。
比如：
逻辑复制：之前 uber 用的物理复制，master 上一个 bug 导致数据损坏一个 bit 写错了，所有的从跟着坏。
Replica 事务糙：猜 Replica 的事务快照是怎么实现的？开一个事务快照 == 停止主从复制。
写放大 + Replication 流量放大：与 MySQL 二级索引不同，postgres 的索引指向的也是个物理位置，写入数据时，即使索引的值未变化，也要更新索引指向的物理地址，存在一点写放大，在物理复制的场景下，写放大 == 流量放大。
连接管理：postgres 一个连接一个进程，这时候你才想起来线程竟然是个轻量的东西。
MySQL 给人的感觉就是「我啥都挫，要啥特性没啥特性，事务都用起来没多少年，但是我十二十年前就有主从逻辑复制跟 MHA」。
链接：
https://www.zhihu.com/question/31955622/answer/1625519578
❝作者：灵剑
这可能还真的跟PHP有点关系，PHP很早的版本就有内置的mysql支持，很多Linux发行版都可以一键安装LAMP套件（Apache + MySQL + PHP），基本不用配置就可以开始用。
其实国内PHP流行的时候已经有pgsql的支持了，但是习惯和早期沿袭的资料的影响仍然是巨大的。因为MySQL用的多，自然熟悉MySQL的DBA也多，熟悉pgsql的DBA少，也就进一步影响了其它语言的选型。
对于当时的大部分开发者和公司来说，pgsql的那些高级功能反正也不会用，自然就跟不存在没什么两样。
链接：
https://www.zhihu.com/question/31955622/answer/1626090963
❝作者：阿哲
PostgreSQL在全球也是二线，不独中国。
PostgreSQL一直就功能比MySQL完备，唯独缺乏一个引爆点，导致生态长期不如MySQL。直到Oracle抄了MySQL的底，逼不少人不得不开始转用PostgreSQL。所以最近两年PostgreSQL有点起势，否则还要继续隐身。
MySQL如果从数据库特性来看，一开始是相当垃圾的，连事务处理都没有。但是人家命好，lamp（Linux+Apache+MySQL+PHP）组合听过没有？当年自建小网站和论坛的不二之选，背后还有诸如RedHat这样的公司推波助澜。
工程上的东西就是这样，用的人足够多，用的时间足够长，慢慢缺陷都会得到弥补，补不了的总会有人想出其它办法。
特性完备度只是技术选型的一个考量维度，其它诸如易上手程度、使用量、已知问题解决方案、是否很容易招到相关人才、社区活跃度等等也是需要考量的因素。
链接：
https://www.zhihu.com/question/31955622/answer/1637481256
❝作者：罗诗亚
我已经不写代码做技术管理一段时间了，但是有些支持工程师做技术选型的经验，根据业务上的需求来聊一聊吧。这里一半是我们技术选型时TL告诉我的，一半是我个人代码实践哈。
数据库这种早期用了就基本不能换的东西是有滞后性的，你看到现在MySQL的现状，是5年前MySQL是国内几乎唯一选择的情况。5年前Postgres就已经在欧美初创项目里比较受欢迎了，
国内公司数据量、体量是国外公司无法比的，毕竟用户人数多嘛，随便都上亿，而且国外这几年新项目活得好的公司都是B2B，有几十万上百万用户量就很不错了。
Postgres有scaling issue（扩展问题？这个词中文怎么说），一个表2-3T就不行不行的了，不做大量优化查询速度就以秒开始做单位了。题外话，NoSQL也有类似的坏处。但是除非在生产环境中踩过坑，没有人会告诉你的。在技术社区里喷某个解决方案不行是会被鄙视的，特别是大公司，有这种体量业务的工程师是没时间跟你说这种扫兴的话的。
Postgres的好处之一是有好几年给新语言的ORM比MySQL成熟，对全栈工程师更友好。欧美的全栈工程师一般是脚本语言后端（Node RoR Python）加上前端。国内更流行的是强类型语言（Java）后端，一般不会同时前端的，Java + MySQL是真香。欧美这种全栈工程师的弱点就是对后端没有那么深的理解。这里就不细聊了。
前几年不需要运维支持就能部署的云服务提供商（Digital Ocean、Heroku）只支持Postgres。同上，全栈工程师一般是没有运维能力的。EC2上给你装个MySQL？RDS的文档能看懂就很不错了好吗~
MySQL对于你说的那些Postgres优点，都在国内有业界已经验证过，实施经验人数也很多的最佳解决方案。而且那些优点，是工程师做得爽而已，跟业务没啥实质性的关系。而踩过Postgres坑的这种人招不到，才是阻碍业务的第一大要素.
最后，为什么都是data类才用PG，因为data不是业务组，运维支持力度没那么大，也没有实时性能上的压力，上面的坏处不是什么坏处，好处却是可见的，能够提高开发速度的。
写得不对的请勿喷，哈哈。
链接：
https://www.zhihu.com/question/31955622/answer/1640686511
❝ 作者：李新野
小项目无所谓了，用起来都差不多。公司一大，数据量一大的话两个都不行。都要用非关系式数据库。而非关系式数据库说到底就是没有数据库，一切功能都要自己写。
我不喜欢谈“技术”就是因为这样。程序尤其是后端都很无聊、前端又充满三本转正JS程序员，还可能遇到友善度产品经理。所以我看着很多二流程序员为了某个“技术”的优劣争论不休总是觉得很可笑。无聊透顶、还不如回澄海教书。
链接： https://www.zhihu.com/question/31955622/answer/1637406028
来源：数据与人
