阿里云RDS的启示录，不搞兼容搞创新，客户才能给钞票

❝

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，可以解决你的问题。加群请联系 liuaustin3 ，（共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9）(1 2 3 4 5 6 7 8群已经爆满  9群 300+，开10群PolarDB专业学习群110+)

国产数据库兼容性的问题，我的态度非常明确，不应该再以兼容性作为国产数据库的卖点，无论是技术，还是宣传，上周五有人说我站着说话不腰疼。

然后我用反讽的手段，做了一次以国产数据库兼容性为宣传的文章，骂声一片。评论区大部分都是没看明白是反讽，误认为我认同国产数据库兼容性。

今天我们用一个实例来说说，一个最应该搞兼容的数据库产品，却在这两年反其道而行，搞上独立的数据库技术。

这个主人公就是阿里云的RDS产品，MySQL和PostgreSQL 开源的数据库产品，从普通人的认知，RDS托管产品就应该完全遵从开源的数据库体系，做到原汁原味的把线下的开源数据库产品，转移到云上，大部分的云厂商也是这么做的。

而我看到的阿里云的RDS产品，完全不是这样的，阿里云的RDS数据库产品完全是从客户的角度作为出发点，不会将兼容作为一个卖点，或者原汁原味作为一个卖点，来营销RDS数据库。

从数据库产品的角度，阿里云的RDS数据库产品是一个青出于蓝的数据库产品，依从客户的角度，如果我拿到的一个阿里云的MySQL,阿里云的PostgreSQL 和我线下的数据库自建的产品完全一致，我的自己先问自己一个问题，我有必要买阿里云的RDS数据库产品吗？ 我为什么自己不自建呢？

阿里云的RDS产品给提出这样问题的人，一个非常好的产品角度的回复。阿里云的RDS产品不是搞照搬开源产品，以兼容作为一个卖点。

我们看下面的几个截图

上面两个图，可以回答，为什么客户不自建MySQL或者PostgreSQL开源数据库产品。这就是不以兼容性，而从客户的实际使用的角度出发，解决客户真实问题的视角设计出来的阿里云的RDS MySQL 和 RDS PostgreSQL.

他们都可以自动挂接 DuckDB,通过数据复制的技术将MySQL 或者PostgreSQL的动态数据复制到DUCKDB，并将DUCKDB 作为一个PG或MySQL的从节点，让动态数据完全与主库同步。其中的需求来自于客户在使用MySQL,PG中的OLAP的需求，无论是出于解决客户复杂SQL无法在MySQL,PG中进行执行的难题，还是从客户的角度一些业务必须要挂接报表系统，为客户产出对应的报表数据的需求。

这一切都是在真心的解决客户头疼的难题，他们并不以自己为中心，也不臆想客户的需求而杜撰出来一些“美丽”但不实用的功能。因他们非常明确，客户如果有真实的需求，他们会用钞票来给阿里云的RDS产品投票，RDS的产品强势的销售额说了这一切。

比如，MySQL 大家都在吐槽MySQL没有如PG强有力的支持向量计算，他们就在RDS MYSQL上搞出了向量计算，让使用RDS MYSQL的客户有了在MySQL上可以进行向量计算的能力，而不用再去PostgreSQL上去学习新的数据库产品的使用方式。

包括明天在杭州召开的第一届，AliSQL DuckDB开源发布会,作为一个用户，我也实在没有想到一个RDS产品的提供商，会搞开源自己的产品。 

https://page.aliyun.com/form/act1162737496/index.htm?spm=5176.29361554.J_4BRJ3a1cjotOn8nraHZ4y.1.4b243e66ozFg7L

从阿里云的RDS产品这两年的变化，比如去年我去试用的在PostgreSQL 产品中挂在了PG和DUCKDB双引擎，一个PG数据库编程了OLAP + OLTP的数据库产品。我认识到一个关键的点。

阿里云的RDS团队已经不把数据库当数据库对待了，他们把数据库当成一种交付能力来对待，这对客户是负责的，他们并不以一个数据库作为一个产品交付给客户，那样已经不是当下一个成熟的数据库厂商的所作所为，他们把数据库当成一种服务，提供客户需要的服务能力，无论是MySQL 还是PG 对阿里云RDS来说都不重要，重要的是可以满足客户的核心业务需求，同时可以在既有的MySQL或PostgreSQL上满足这一切。

除此之外，去年我还评测了阿里云RDS产品的升级数据库版本的三种方式，三种方式分别服务不同的客群，大型企业，中型企业，以及小型企业，有从成本考虑的服务方式，有从企业要求严谨性角度提供服务的方式。

所以阿里云的RDS产品是成功的，成功的让客户掏钱，真正成熟的数据库产品，最终一定会背叛兼容性，只因他真实的从客户的角度出发为客户负责，而不是为了想象中的所谓的“标准”负责。