12同行回答
这个需要结合业务系统来看，如果是分析型的可以考虑基于PG的产品，比如gaussdb，TDSQL-PG版本，如果是交易型的可以基于MySQL的，比如TDSQL-MYSQL版本，goldendb等等，如果是混合负载可以考虑国产纯自研的如TIDB，OB等等。
收起提供一个我司的选型思路供参考。
首先，结合业务去考虑数据库选型。比如评估下业务代码中数据库语句类型和占比有哪些，有没有用到一些特殊的功能如存储过程。结合这些代码去测试数据库，评估下对业务代码的兼容性有多大，需要做的代码改造量有多少，从成本角度考虑是否可接受。
其次，做poc测试。除了数据库本身的功能外，结合业务逻辑去测。做功能测试、性能测试。
最后，才是数据库的选择。
此外，也得考虑去O的成本、是否要求自主可控。
收起虽然msql用的非常的多，特别是电商领域。还有很多互联网大厂都喜欢用MYSQL。但是我个人认为MYSQL对比 PG有极其强悍的 SQL 编程能力。特别很多函数或者原来ORACLE实现的语法，可以简单迁移或者对照换个替换函数使用。但是MYSQL在这方面就差了一些。
此外PG在GIS、JSON和数组等比MYSQL支持的多一些。
PG对插件的支持比MYSQL好，可以很好的弥补和扩展功能
当然PG的流复制与MYSQL的BINLOG比还是差了不少，特别还有在电商的单笔查询或者根据主键查询，PG的性能是弱于MYSQL的。
主要还是看使用的场景如何。 一般的说 电商用MYSQL 分析类用PG。
在去O过程中，我们先明确一点，没有数据库产品是可以完全替代的。即完成去O工作，是需要通过“应用改造+数据库选型+应用迁移”，结合在一起才能完成。这里需要考虑整体目标及路径。问题中的两种方式，原则上都是可以完成去O工作，但对于应用改造及迁移的影响差异较大。
1.PG类产品，其企业级功能较为完善，使用体感与Oracle相近。有些基于PG为内核的产品，在Oracle兼容性上做了了大量工作。对用户来说，使用上与Oracle更为相近，甚至大部分可以做到无缝迁移；少部分需要修改上，也相对工作量不大。
2.MySQL类产品，流行程度更高，但与Oracle相比，功能差异较多。如在去O中选用，需做较大的修改。
去O的database应用有选择PG数据库的，也有选择MySQL的，根据应用的特点来选吧；好像大数据量，批处理文件多，import批量数据入库频繁的应用选择PostgreSQL多，面向前台OLTP应用，频繁有批量查询的应用选MySQL的多一点。
收起这个还是看自己的业务场景，PG现在国内社区感觉还是不太好，但是产品的功能还是可以的。
如果使用mysql替换O，还得慎重考虑，mysql只适合业务场景比较简单的，如果数据量和业务量比较大，得分库分表，后续维护起来比较麻烦。
个人感觉，如果真要替换O，也不一定非得用PG和MYSQL，也可以考虑其他国产数据库，综合考虑。
去O是重点
其实去O本来不难。难就难在业务系统的适配，难就难在很多很多业务系统和某个数据库绑定的特别特别死，无法拆分，最终数据库兼容性成了重点。
真正数据库要能够解决的核心问题就是事务和并发性。
无论哪个应用开发商都应该把业务逻辑尽最大可能的从数据库是迁移出去
数据库只做数据库该做的擅长的事情即可。
收起国产数据库去O，当前主要是金融行业和政企。这些用户都是oracle等商业数据库的深耕用户，重度依赖数据库的能力，甚至用了很多存储过程来加速处理性能。
那么PG产品和mysql产品哪个合适？mysql用的那么广泛，是否能承担去O的重任？
从相似度来说，PG数据库比mysql更像Oracle，无论是数据库对象的概念，还是数据库内的组件概念。但是落到技术的细节上，其实每个数据库都天差地别。
mysql基于主键索引组织的表，PG的追加更新存储引擎，和oracle相比从根子上差异就很大。所以最终还是落到用户的使用场景上来比较。
oracle的深度用户的应用场景是广泛的，基本上属于HTAP的场景。
mysql比较适合纯tp的使用场景，对于复杂sql的支持能力一直很弱。
而PG相对好一点。从这点来说，如果不做sql改造调优，PG产品适用性更好。在存储过程的支持上，PG也比mysql要好，当然这些还是需要迁移改造的成本，并非无缝迁移。
除了适用的场景外，我们还需要关注pg和mysql的其他能力。例如产品的成熟度，生态的成熟度。mysql作为简单的数据库，在互联网企业中深度使用。因此产品的能力，缺陷都很清楚。周边的生态也是mysql要好一些，周边工具的支持通常都会先支持mysql。
而PG在这方面相对差一些，所以出于对可靠性，稳定性等方面的考虑，使用PG产品还需要时间来催熟。
总结一下就是这两类产品都可选，摒弃弱项，选择强项，依据业务的场景（性能，可靠性等）来选择合适的数据库，用得好就是好的去O数据库。
收起