云数据库是不是智商税？定价荒谬、性能平平，安全可靠也是笑话|postgresql|云数据库|智商税|服务器|源代码

寒冬来袭，大厂纷纷开始裁员，进入降本增效模式，作为公有云杀猪刀一哥的云数据库，故事还能再讲下去吗？

近日，Basecamp & HEY 联合创始人 DHH 的一篇文章【1】【2】引起热议，主要内容可以概括为一句话：

“我们每年在云数据库（RDS/ES）上花50万美元，你知道50万美元可以买多少牛逼的服务器吗？我们不做冤大头要下云了，拜拜了您呐！

所以，50万美元可以买多少牛逼的服务器？

云数据库是不是智商税？荒谬的定价成本刺客足够好吗？适用的场景让DBA下岗？垄断的威胁应对的方案参考

荒谬的定价

公有云上什么最花钱？正常来说，如果不是把公有云单纯当作一个 IDC 2.0 或者 CDN供应商来用，最费钱的服务就是云数据库。公有云上的存储、计算、网络资源贵吗？严格来说不算特别离谱。IDC托管物理机代维的核月成本大约为二三十块，而公有云上一核 CPU 算力用一个月的价格，大概在七八十块到一两百块，考虑到各种折扣与活动，以及弹性溢价，基本处于薄利多销的状态。

公有云上的存储、计算、网络资源贵吗？严格来说不算特别离谱。IDC托管物理机代维的核月成本大约为二三十块，而公有云上一核 CPU 算力用一个月的价格，大概在七八十块到一两百块，考虑到各种折扣与活动，以及弹性溢价，基本处于薄利多销的状态。

计算资源价格（元/核·月）：公有云定价通常在几十到一两百不等

不过云数据库就非常离谱了，同样是一核算力用一个月，云数据库价格比起对应规格的硬件可以翻几倍乃至十几倍。便宜一些阿里云，核月单价三四百，贵一些的 AWS，核月单价可以上千。

云数据库资源价格（元/核·月）：公有云定价通常在几百到一两千

云数据库的定价模型基本上都是对应硬件资源价格（EC2）乘以某一个倍率。例如，阿里云 RDS PG （基础版）与同规格 ECS 定价的关系就是 RDS = 2.3 x ECS，而在AWS上，这个倍率则会更高。

AWS 96C 384G m5.24xlarge， RDS是EC2 十倍的价格。

作为一条经验法则，租一年云数据库的成本，差不多够你买两三台更好规格的服务器放在IDC里托管。

单价二十块的硬件，为什么可以卖出几百甚至上千的价格来，究竟是服务器是金子做的，还是RDS是金子做的？

常用的话术是：数据库是基础软件里的皇冠明珠，凝聚着无数无形知识产权BlahBlah。因此软件的价格远超硬件，是非常合理的。如果是Oracle这样的顶尖商业数据库，这么说也有些道理。但公有云上的云数据库，本质上就是免费开源数据库内核换皮封装魔改，加上自己管控软件和共享DBA人头服务。那这种溢价率就非常荒谬了。

公有云的秘密就在这里：用廉价的存算资源获客，用云数据库杀猪。

尽管国内公有云 IaaS （存储、计算、网络）的收入占营收接近一半，但毛利率只有 15% ～ 20%，而公有云 PaaS 的营收虽然不如 IaaS，但 PaaS 的毛利率可以达到 50%，完爆卖资源吃饭的 IaaS 。而 PaaS 中最具代表性的，就是云数据库。

成本刺客

公有云上什么最花钱？正常来说，如果不是把公有云单纯当作一个 IDC 2.0 或者 CDN供应商来用，最费钱的服务当属数据库。

在我职业生涯的第一站中，一次杀猪经历让我记忆犹新：作为前几个被逼上A云的内部BU，A云直接出工程师加入手把手提供上云服务。用ODPS全家桶换掉了自建的大数据/数据库全家桶。应该说服务确实不错，只不过每年的存储计算开销从千万出头飙升到接近一亿，利润几乎都转移到A云了。

在第二站则完全不同，我们有两万五千核规模的 PostgreSQL 与 Redis 数据库集群。这个规模如果用云数据库，即使打到骨折，每年一两亿还是要的；甚至，如果说按照WCU/RCU的计费模式，费用可以干到每年十亿量级。但结果是，我们两三个DBA，几个运维，以每年不到一千万的总成本（人年工资+机器5年折旧+IDC托管代维均摊）便支撑起这样规模的服务，而且做的相当不赖，四五百万的QPS，可用性普遍在5个9以上。

以我们自己使用的数据库机型为例， DELL R730 64核CPU 384GB内存 + 3TB NVME SSD，跑PostgreSQL单台点查QPS几十万，写入TPS十几万，性能澎湃。采购价七万五一台，高可用数据库集群至少两台，以五年折旧计，每年成本三万块。

而类似规格的云数据库，以阿里云RDS PG高可用版独享64C 512G pg.x8.8xlarge.2c为例，不同付费模式折合的每年成本如下表所示。

这玩意自建的价格合每年3万，看看溢价率有多高？AWS RDS只会更贵。

总的来说，在不考虑人工成本的情况下，打成骨折的云数据库，还是比同规格自建贵了几乎有十几倍，多么疯狂！（人工成本后面再说）

足够好吗？

只要东西足够好，单纯贵并不是问题。那么问题就来了，RDS足够好吗？

应该说，对于玩具应用，微型网站，个人托管，野路子土法自建数据库来，毫无技术能力与认知的甲方说，RDS足够好了。但在高净值客户群体与数据库专家看来，云数据库RDS不过是及格线上的大锅饭产品罢了。说到底，公有云源于大厂内部的运维能力外溢，对大厂大可不必有什么莫名的崇拜。（Google也许算个例外，它的问题恰好相反）。

以性能为例，性能的核心指标是延迟/响应时间，特别是长尾延迟，会直接影响用户体验。在这一点上，云数据库的性能表现就非常之拉垮。在小规模的Bench测试中，所有工作集都在内存中，有时候看不出来这一点。但实际跑起来一旦内存缓冲区没有命中访问存储，延迟会立刻从几十微秒飙升到几十毫秒。这样的长尾延迟经过几次应用倍乘放大，对于用户体验来说非常致命：没有人愿意等着每个操作都要转几秒圈圈（银行App差不多就是这种）。

在我们自己的业务里使用的是本地NVME SSD，典型性能表现为读写延迟几十个微秒（3.2TB / MLC ），一条简单读/写查询的响应时间在PG侧为 100～200µs，在应用侧的端到端请求延迟通常为 200 ～ 500µs，超过1毫秒的查询都会视作异常慢查询。而云数据库底层使用的EBS服务本身延迟就非常之高，例如，AWS默认的GP3默认8K读写延迟稳定为40ms，io1规格延迟约为10毫秒，云数据库光是磁盘IO延迟就能给你干到十毫秒的数量级，你说这咋整？【4】

确实，有时候云厂商会提供性能足够好的本地的NVME SSD，但都会非常鸡贼的设定各种限制条件，来避免用户来使用EC2来自建数据库。AWS的限制方式是 ephemeral storage，这种本地盘一旦遇上EC2重启就自动抹干净了。阿里云的限制方式是给你卖天价，例如ESSD PL3 定价为 38.4 ¥ / GB·年，一块3.2TB的磁盘用一年要收12万，好家伙，用一年这钱够你买20块这样的磁盘了。所以在成本上，无论是RDS本体还是存储，都是纯纯的杀猪智商税。

再以可观测性为例，没有一家RDS的监控能称得上是“好”。就以监控指标数量来说吧，虽然说知道服务死了还是活着只需要几个指标，但如果想进行故障根因分析，需要越多越好的监控指标来构建良好的Context。而大多数RDS都只是做了一些基本的监控指标，和简陋到可怜的监控面板。以阿里云RDS PG为例【4】【5】，所谓的“增强监控”，里面只有这么点可怜的指标， AWS里和PG数据库相关的指标也差不多不到100个。

而我们自己的监控系统里主机指标有800多类，PGSQL数据库指标610类，REDIS指标257类，整个大约三千类指标，在数量上完爆这些RDS。一个公开的Demo可以在这里看到：http://demo.pigsty.cc 。

至于可靠性，都不想说12月香港机房那场丑闻了，租的机房，服务器喷水消防，OSS故障，然后阿里云自己整个Region的管控服务竟然因为一个AZ故障自己尿掉了，大量RDS不可用也切不了，让异地容灾成了一个大笑话。不是说自己建就不会出这些问题，稍微靠谱点的IDC托管都不会有这么离谱的事。安全性也闹过几次大笑话，著名的SHGA；一堆样例代码里硬编码AK/SK，你说云RDS更安全？别搞笑啦，经典架构起码还有VPN堡垒机扛着，公网上暴露端口的数据库简直不要太多。

云数据库另一个广为人所诟病的是可扩展性。RDS是不给用户dbsu权限的，这也意味着用户是不能在数据库中安装扩展插件的，而 PostgreSQL 的插件恰恰就是其醍醐味，没有扩展的PostgreSQL就像可乐不加冰，酸奶不加糖一样。当然更严重的问题是，在一些故障出现时，用户甚至都丧失了自我救助的能力。参见：《云数据库：从删库到跑路》中的真实案例，WAL归档与PITR这么基础性的功能，在RDS中竟然是一个付费的升级功能。至于可维护性，有些人说云数据库可以点点鼠标就创建销毁多方便呀，说这话的人肯定没经历过重启每个数据库都要收手机短信验证码的sb场景。有 Database as Code 式的管理工具，真正的工程师绝对不会用这种“ClickOps”。

不过任何事物存在都有其道理，云数据库也不是一无是处，起码在可伸缩性上，确实是整出了一些花活。除此之外，确实没有什么能吹嘘的了。

适用的场景

no silver bullet

选型一款数据库，需要从许多维度出发：稳定性，可靠性，安全性，简单性，可伸缩性，可扩展性，可观测性，可维护性。公有云的鼓吹者很喜欢往云脸上贴金：节约成本，灵活弹性，安全可靠，是企业数字化转型的万灵药，是电动车对马车的革命，既要又要。但绕开这些虚头巴脑的东西，相比专业的数据库服务，云数据库真正占有优势的只有一条：弹性。具体来说是两点：启用成本低，可伸缩性强。

启动成本低，说的是你不需要进行机房建设，服务器采购就可以开始用，当然代价是高到离谱的维护成本。可伸缩性强，指的是各种配置升降配，扩缩容比较容易。因此，公有云真正适用的场景就是这两种：

起步阶段，流量极小的简单应用
毫无规律可循，大起大落的负载

前者主要包括简单网站，个人博客，小程序小工具，演示/POC，试水性Poc/Demo。后者主要包括低频的的数据分析/模型训练，突发的秒杀抢票，明星并发出轨等。

公有云的场景其实类似于共享充电宝，出门在外，共享充电宝可以解决临时应急性的小规模充电需求。但对于大量日常在家/单位两点一线的人来说，每天用它给手机电脑乃至电车充电，毫无疑问是荒谬的。共享充电宝租一个小时4块钱，租几个小时的钱，就够你把它直接买下来了。

租车可以很好的满足临时的、突发的、一次性用车需求：外地出差旅游，临时拉一批货。但如果你的出行需求是频繁的，粗略可预测的，那么购置一辆自动驾驶的车也许是最省事省钱的选择。房子的租售比二三十年，汽车的租售比五六年，而公有云服务器的租售比通常只有几个月，如果你的业务稳定活几个月，为什么不买而要租呢？

所以，云厂商赚的钱，要么是VC投出来的朝不保夕的科技创企，要么是信息不对称人傻钱多的大户，要么是灰色空间比云溢价还高的特殊单位，要么是个人站长/学生/VPN用户。聪明的高净值客户，谁会放着便宜舒适的大House不住，跑去挤着租住方舱医院人才公寓呢？

如果为了不需要的灵活性与弹性支付几倍乃至十几倍溢价，这是纯纯的智商税。

让DBA下岗？

另一种云数据库的鼓吹论点是，用了RDS，你就不用DBA啦。我们有数据库自治服务，RDS能帮你解决这些数据库相关的问题，DBA都要下岗了。我相信，任何认真看过这些‘自治服务’文档【6】【7】的人都不会说出这种可笑的话出来：这种连一个好用的监控系统都算不上的小模块，能让数据库自治起来？

DBA的由来

很多地方都需要DBA：糟糕的模式设计，奇烂的查询性能，鬼知道有没有用的备份；等等等等。可惜的是，从事软件工作的人中，很少有人了解什么是DBA。成为DBA，意味着与研发人员创造的熵进行永无休止的战斗。

DBA，Database Administrator，数据库管理员，以前也叫做数据库协调员、数据库程序员。DBA是一个横跨于研发团队与运维团队的广博角色，涉及DA、SA、Dev、Ops、以及SRE的多种职责，负责各种与数据与数据库有关的问题：设置管理策略与运维标准，规划软硬件架构，协调管理数据库，验证表模式设计，优化SQL查询，分析执行计划，乃至于处理紧急故障以及抢救数据。

DBA的第一点价值在于安全兜底：他是企业核心数据资产的守护者，也是可以轻易对企业造成致命伤害的人。在蚂蚁金服有个段子，能搞死支付宝的，除了监管就是DBA了。高管们通常也很难意识到 DBA 对于公司的重要性，直到出了数据库事故，一堆CXO紧张地站在DBA背后观看救火修复过程时…。

DBA的第二点价值在于性能优化。许多公司并不在乎他们的查询是纯狗屎，他们只是觉得“硬件很便宜”，砸钱买硬件就好了。然而问题在于，一个调整不当的查询/SQL或设计不当的数据模型与表结构，可以对性能产生几个数量级的影响。总会在某一个规模，堆硬件的成本相比雇佣一个靠谱DBA的成本高得令人望而却步。实话说，我认为大多数公司在IT软硬件开销中花费最大的是：开发人员没有正确使用数据库。

优秀的DBA还会负责数据模型设计与优化。数据建模和SQL几乎已成为一门失传的艺术，这类基础知识逐渐为新一代工程师遗忘，他们设计出离谱的模式，不懂得正确地创建索引，然后草率得出结论：关系型数据库和SQL都是垃圾，我们必须使用糙猛快的NoSQL来省时间。然而人们总是需要可靠的系统来处理关键业务数据：在许多企业中，核心数据仍然是一个常规关系型数据库作为Source of Truth，NoSQL数据库仅用于非关键数据。

在一个大型组织中，一个好的DBA是至关重要的。不过好的DBA相当稀有，以至于这个角色在大多数组织中只能外包：包给专业的数据库服务公司，包给云数据库RDS服务团队，或者内包给自己的研发/运维人员。

DBA的未来

尽管DBA/数据库专家对于大型组织与大型数据库而言非常重要，不幸的是，DBA作为一份职业前景可能确实是晦涩暗淡的。大趋势是数据库本身会越来越智能，易用性越来越好，而各式各样的工具、SaaS、PaaS不断涌出，也会进一步压低数据库的使用门槛。公有云/私有云DBasS的出现更是让数据库的门槛进一步下降，只要掏钱就可以迅速达到优秀DBA的廉价七成正确水准。而数据库的专业技术门槛降低，将导致DBA的不可替代性降低：安装一套软件收费十几万，做一次数据恢复上百万的好日子肯定是一去不复返了。

无论是公有云厂商，还是以Kubernetes为代表的云原生/私有云，或者是类似 Pigsty 【8】这样的本地开源RDS替代，其核心价值都在于尽可能多地使用软件，而不是人来应对系统复杂度。那么，云软件会革了运维与DBA的命吗？好的软件可以解决70%的高频问题，然而总是会有那么一些低频的，复杂的需要人才能处理。

根据复杂度守恒定律，无论是系统管理员还是数据库管理员，管理员这个岗位消失的唯一方式是，它们被重命名为“DevOps Engineer”或SRE。云并不会消灭管理员，你可能需要更少的人手来打理这些云软件，但总归还是需要人来管理的：从整个行业的视角看，云软件的推广会让100个初中级运维（传统系统管理员）的工作岗位变成10个中高级运维岗位（DevOps/SRE），同样的事也有可能发生在DBA身上。例如，现在也出现了与SRE相对应的DRE：Database Reliability Engineer。

DBA的岗位会发生分化，运维性，事务性的工作会逐渐剥离消亡，而管理性、业务性的工作内容占比会加大。顶尖的数据库专家永远不会担心失业问题，也许换一个新的名字：与SRE相对应的DRE：Database Reliability Engineer。中上的DBA的岗位会因为软件替代减少，而初级DBA，或者内包为‘初级DBA’得研发运维人员，会因为管控软件的门槛降低而增多。

RDS确实让一部分DBA下岗了，但在自我革命这件事上，云数据库是不可能干过顶尖DBA的。RDS既然先不仁，就不要怪DBA不义了。

垄断的威胁

我们更需要担心的是这样一幅图景，公有云（或果子云）坐大，控制硬件与运营商上下游，垄断计算，存储，网络，顶尖专家资源。想要用好数据库，必须用昂贵的RDS才行。而只要掌握这些关键少数，就可以控制整个互联网。这毫无疑问与互联网的初心愿景背道而驰的。引用 DDIA 作者 Martin Kelppmann 的一段话【9】来说：

在2020年，计算自由的敌人是云计算软件
—— 即主要在供应商的服务器上运行的软件，而你的所有数据也存储在这些服务器上。典型的例子包括：Google Docs、Trello、Slack、Figma、Notion和其他许多软件。
这些“云软件”也许有一个客户端组件（手机App，网页App，跑在你浏览器中的JavaScript），但它们只能与供应商的服务端共同工作。而云软件存在很多问题：

如果提供云软件的公司倒闭，或决定停产，软件就没法工作了，而你用这些软件创造的文档与数据就被锁死了。对于初创公司编写的软件来说，这是一个很常见的问题：这些公司可能会被大公司收购，而大公司没有兴趣继续维护这些初创公司的产品。
谷歌和其他云服务可能在没有任何警告和追索手段的情况下，突然暂停你的账户。例如，您可能在完全无辜的情况下，被自动化系统判定为违反服务条款：其他人可能入侵了你的账户，并在你不知情的情况下使用它来发送恶意软件或钓鱼邮件，触发违背服务条款。因而，你可能会突然发现自己用Google Docs或其它App创建的文档全部都被永久锁死，无法访问了。
而那些运行在你自己的电脑上的软件，即使软件供应商破产了，它也可以继续运行，直到永远。（如果软件不再与你的操作系统兼容，你也可以在虚拟机和模拟器中运行它，当然前提是它不需要联络服务器来检查许可证）。例如，互联网档案馆有一个超过10万个历史软件的软件集锦，你可以在浏览器中的模拟器里运行！相比之下，如果云软件被关闭，你没有办法保存它，因为你从来就没有服务端软件的副本，无论是源代码还是编译后的形式。
20世纪90年代，无法定制或扩展你所使用的软件的问题，在云软件中进一步加剧。对于在你自己的电脑上运行的闭源软件，至少有人可以对它的数据文件格式进行逆向工程，这样你还可以把它加载到其他的替代软件里（例如OOXML之前的微软Office文件格式，或者规范发布前的Photoshop文件）。有了云软件，甚至连这个都做不到了，因为数据只存储在云端，而不是你自己电脑上的文件。

如果所有的软件都是免费和开源的，这些问题就都解决了。然而，开源实际上并不是解决云软件问题的必要条件；即使是闭源软件也可以避免上述问题，只要它运行在你自己的电脑上，而不是供应商的云服务器上。请注意，互联网档案馆能够在没有源代码的情况下维持历史软件的正常运行：如果只是出于存档的目的，在模拟器中运行编译后的机器代码就够了。也许拥有源码会让事情更容易一些，但这并不是关键，最重要的事情，还是要有一份软件的副本。
我和我的合作者们以前曾主张过本地优先软件的概念，这是对云软件的这些问题的一种回应。本地优先的软件在你自己的电脑上运行，将其数据存储在你的本地硬盘上，同时也保留了云计算软件的便利性，比如，实时协作，和在你所有的设备上同步数据。开源的本地优先的软件当然非常好，但这并不是必须的，本地优先软件90%的优点同样适用于闭源的软件。
云软件，而不是闭源软件，才是对软件自由的真正威胁，原因在于：云厂商能够突然心血来潮随心所欲地锁定你的所有数据，其危害要比无法查看和修改你的软件源码的危害大得多。因此，普及本地优先的软件显得更为重要和紧迫。如果在这一过程中，我们也能让更多的软件开放源代码，那也很不错，但这并没有那么关键。我们要聚焦在最重要与最紧迫的挑战上。

应对的方案

我希望未来的世界人人都有自由使用优秀服务的事实权利，而不是只能被圈养在几个公有云厂商提供的猪圈里吃屎。这就是为什么我要做 Pigsty，一个更好的，开源免费的 PostgreSQL RDS替代。让用户能够在任何地方（包括云服务器）上，一键拉起有比云RDS更好的数据库服务。

Pigsty是对云数据库的辛辣嘲讽，也是对 PostgreSQL 的彻底补完。Pigsty 是 Postgres in Great STYle 的缩写，即“全盛状态下的 PostgreSQL”。它是一个完全基于开源软件的，可以运行在任何地方的，浓缩了 PostgreSQL 使用管理最佳实践的，Me-Better RDS 开源替代。Pigsty就是用真实世界的大规模，高标准 PostgreSQL 集群打磨而来的解决方案，它是为了满足我们自己管理数据库的需求而诞生的。它在八个维度上进行了许多工作：

可观测性（Observability）是天；天行健君子以自强不息；Pigsty使用现代可观测性技术栈为 PostgreSQL 打造了一款无与伦比的监控系统，从全局大盘概览到单个表/索引/函数等对象的秒极历史详情指标一览无遗，让用户对系统能够做到洞若观火，进而掌控一切。此外，Pigsty的监控系统还可以独立使用，监控第三方数据库实例。

可控制性（Controllability）是地；地势坤君子以厚德载物；Pigsty提供Database as Code的能力：使用表现力丰富的声明式接口描述数据库集群的状态，并使用幂等的剧本进行部署与调整。让用户拥有精细定制的能力的同时又无需操心实现细节，解放心智负担，让数据库操作与管理的门槛从专家级降低到新手级。

可伸缩性（Scalability）是水；水洊至习坎君子以常德行；Pigsty提供预制通用调参模板（OLTP / OLAP / CRIT / TINY），自动优化系统参数，并可通过级联复制无限扩展只读能力，也使用Pgbouncer连接池优化海量并发连接；Pigsty确保 PostgreSQL 的性能可以在现代硬件条件下充分发挥：单机可达数万并发连接/百万级单点查询QPS/十万级单条写入TPS。

可维护性（Maintainability）是火；明两作离大人以继明照于四方；Pigsty 允许在线摘除添加实例以扩缩容，Switchover/滚动升级进行升降配，提供基于逻辑复制的不停机迁移方案，将维护窗口压缩至亚秒级，让系统整体的可演化性，可用性，可维护性提高到一个新的水准。

安全性（Security）是雷；洊雷震君子以恐惧修省；Pigsty提供了一套遵循最小权限原则的访问控制模型，并带有各种安全特性开关：流复制同步提交防丢失，数据目录校验和防腐败，网络流量SSL加密防监听，远程备份AES-256防泄漏。只要物理硬件与密码安全，用户无需担心数据库的安全性。

简单性（Simplicity）是风；随风巽君子以申命行事；Pigsty旨在以最小的复杂度成本交付完整的RDS功能，模块化设计允许用户自行组合选用所需的功能。Pigsty提供基于Vagrant的本地开发测试沙箱，与Terraform的云端IaC一键部署模板，让您在任意新EL节点上一键完成离线安装，完整复刻环境。

可靠性（Reliability）是山；兼山艮君子以思不出其位；Pigsty提供了故障自愈的高可用架构应对硬件问题，也提供开箱即用的PITR时间点恢复为人为删库与软件缺陷兜底，并通过长时间、大规模的生产环境运行与高可用演练验证其可靠性。

可扩展性（Extensibility）是泽：丽泽兑君子以朋友讲习；Pigsty深度整合PostgreSQL生态三大核心扩展PostGIS、TimescaleDB、Citus 、以及大量扩展插件；Pigsty提供模块化设计的Prometheus/Grafana可观测性技术栈，以及MINIO，ETCD，Redis、Greenplum 等组件的监控与高可用部署与PostgreSQL 组合使用；

更重要的是，Pigsty是完全开源免费的自由软件，采用 AGPL v3.0 协议，也提供免费的社区支持和答疑，这一部分主要是靠的是社区专家与用户的情怀用爱发电。所以，您可以用20块的纯硬件成本运行功能完备，甚至更好的RDS服务。

尽管Pigsty 本身旨在用数据库自动驾驶软件替代人肉数据库运维，但再好的软件也没法解决 100% 的问题。优秀的软件可以解决80% 的高频常见问题，但是总会有 20% 的冷门低频疑难杂症，需要专家来介入处理。这也是为什么我们也提供专业的商业支持与订阅服务，来为有需要的企业级用户使用 PostgreSQL 与 Pigsty 兜底。Pigsty帮助用户用好 PostgreSQL，而我们帮助用户用好 Pigsty。