以下内容纯属个人看法

云数据库的RDS 产品，在传统开源的系列里面大致可以选择的是 POSTGRESQL 和 MYSQL 两种，诚然在RDS 的里面大部分产品最终的选择还是MYSQL ，今天不想讨论产品的量，而是想讨论以下产品的难度，RDS 产品在 POSTGRESQL 和 MYSQL 两种产品的难度问题。

先说结果，POSTGRESQL 的难度要大于 MYSQL 的难度。

原因如下

1  POSTGERSQL 的灵活性的问题

POSTGRESQL 在extension中的灵活性太高了，不是一般数据库可以进行比较的，我们以阿里云的 POSTGRESQL 为例在extension 中提供的shared_preload_libraries 为例  阿里云postgresql 支持的相关的extension加载在 shared_preload_libraries 的就有 15个之多。其中包含了，我们常用的 pg_stat_statements, auth_delay, passwordcheck,auto_explain,  pgaudit, pg_prewarm.  

也有阿里云自有的一些PG 特殊的extension 如  index_advisor (这个可以研究完毕写一期)，pg_bigm, pg_hint_plan 等等弥补PG 本身功能不足的extension . 

凭借这些，在数据库的初始化以及数据库的功能复杂性方面，PG在研发中的难度就要高于 MYSQL RDS 。

而相关的团队在POSTGRESQL RDS 上面在这些部分的支持的难度也要高于MYSQL RDS 部分。

2  PG 参数的灵活性和维护性

PG 在参数的复杂性方面也是要高于 MYSQL RDS 产品的，主要体现在一下几个方面

postgresql extension  插件带来更多的参数，这点和MYSQL RDS 不同，基于POSTGRESQL extension 功能的加入，更多的配置参数需要被维护和扩展，导致不属于PG 原生的参数的其他参数的维护数量并不小，而且这些参数的维护和开放，也直接和PG RDS 数据库的稳定性和相关的使用的便利性有关，所以在技术含量上看，PG 的技术难度要高于MYSQL RDS。

3  PG 本身系统的特性导致核心参数的值开放难度大

PG 中的一些参数的值，直接关系到PG 数据库运行的稳定性，以及后期的维护的安全性，在这些参数中的值开放或不开放，是一个难度，属于众口难调的问题，如autovacuum_max_workers  以及  maintenance_work_mem 这样的参数， RDS 产品如果开放了，针对不懂行的客户会导致调整错误，引擎的数据库性能问题，但如果参数设置的太保守，并且不开发给用户，又会导致资深的PG RDS 用户的摒弃，认为开放度不高，便利性不强，无法调优等。

所以PG 在这部分的RDS 产品很难，左右不是，相对MYSQL 的一些参数来说，技术难度相对来说要大，客户满足难度也大。

4  PG 功能多，导致的维护难度大

相对于MYSQL RDS 产品来说，PG 面对的一些客户在使用PG 时的功能点要更多，例如在PG 中我们可以开启逻辑复制槽，而逻辑复制槽如果维护的不好很容易导致磁盘被疯狂的占用，导致系统 CRASH ，而这部分并不是 PG RDS 产品好控制的，如果控制多了，导致客户放弃PG 直接自建PG ，控制少了，导致PG 在维护逻辑复制槽的不利的情况下，数据库经常 CRASH ，导致客户的投诉， 这点在MYSQL 上是不存在这样的问题。

同时基于PG 的功能，可以变成时序型数据库，或地理位图型的数据库等等的扩展功能，导致这方面的RDS 产品的一线人员，也时刻面临各种各样“奇谈怪论”， 维护成本很高 （使用者的数量 和 维护者的数量投入产出比的问题）。

5  使用 PG 客户 和 MYSQL 客户的质量问题

这单也是PG RDS 产品需要更高技术的一个点，相比较MYSQL 数据库的熟悉度在普通用户中还是有一些基础知识和使用的概念的，例如不能写大事务，不能使用存储过程，触发器，约束，外键，等等，这些大部分客户是知晓的，所以MYSQL RDS 产品主要的问题集中在 查询语句的复杂度和撰写的方式上，问题点相对简单。

而PG RDS 产品面对的客户的质量和知识程度就不高了，大部分客户都是从ORACLE 转移过来的客户，对于PG 基本上知晓的不多，而大部分宣传针对POSTGRESQL 来说，都是基于ORACLE 替代的方案，大部分使用者认为 PG =  ORACLE ，将PG 直接当做ORACLE 使用，这也是导致 PG RDS 问题频出的一个点，造成PG 的客户维护难度高，基于客户不熟悉一些PG 的原理，如MVCC 形成，导致VACUUM ,AUTOVACUUM  等问题，大 长 事务导致系统性能低， 甚至引擎冻结炸弹等问题，给PG RDS 的 口碑上产生了一些不利的影响。

6  PG 的开源版本更迭快，特殊功能修改大，导致RDS 产品维护难度大（大版本）

PG 的开源的版本更迭的块，相对MYSQL 开源的版本更迭的速度也不慢，但是PG 的开源版本的一些核心功能，在每次的版本迭代中都有新的功能出现，这就导致以下问题

1   PG 的新的版本，必须被尽快支持，客户希望用心的PG 的版本来解决现有的一些问题，而更多新加入到PG RDS 的客户也希望能获得更新的版本做为初始版本。

2  PG 的新版本，需要更多的压测和测试，才能推出，基于上面的种种因素，如今年的PG 14 版本的INDEX 缺陷的问题，如果RDS 产品快速推出PG 14的产品，则RDS  产品还需要尽快推出解决方案和 升级方案等等，技术要求自然比 MYSQL RDS 产品的技术含量要求要高。

7  数据承载量导致 PG 的客户的数据量大，导致维护难

这点实际上也是PG RDS 产品维护难度大的一个点，PG 单库，单表的承载力比RDS MYSQL 要高是事实 ，所以客户也知道这点，所以对于POSTGRESQL 使用中，很多都是大表，大数据量的数据库，导致PG 在备份，数据迁移，数据导入导出的技术难度要高于 MYSQL RDS 产品的，小表和小数据库等，出现的问题后PG 解决问题的难度也较 MYSQL 难度大，基于MYSQL 有相关等等开源工具等等 可以解决一部分问题，而POSTGRESQL 在开源的工具中数量少，并且基于RDS 产品的一些特性，一部分可能也无法使用等等，也导致PG RDS 产品维护的技术难度和解决方案难度高。

基于以上因素，PG RDS 产品在大多数云中，想找到一个合适的，高质量的RDS 相对 MYSQL 要难度高，目前PG  RDS 产品支持较好的产品提供商，也是屈指可数的1-2家，也证明了 PG 的 RDS 产品的技术难度，维护难度要比 MYSQL RDS 高。