胖头鱼的技术专栏-486 基于PG，就是套壳？看看国产数据库在底座之上做了什么（20261110）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database
PostgreSQL ACE
10年+数据库行业经验
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP，ITPUB认证专家
圈内拥有“总监”称号，非著 名社恐（社交恐怖分子）
全网同名：胖头鱼的鱼缸
ITPUB：yhw1809
除授权转载并标明出处外，均为“非法”抄袭

最近在不少场合，我都听到一种说法：使用 PostgreSQL 作为底座的国产数据库，都是套壳，这些数据库厂商也没有什么技术实力。

我觉得，这个判断下得太快了。

技术从哪里来，用了哪些开源代码，遵守什么许可证，当然应该交代清楚。但从“用了 PG”直接推到“没有技术实力”，中间还少问了一句：这些厂商在 PG 的基础上，到底做了什么？

基于 PG 说明技术来源；是不是只有一层包装，要继续看它改了什么、解决了什么问题，以及能不能长期维护。如果这些都不看，真正做了研发的产品会被一并否定，换个名字就宣称全部自研的产品反而可能蒙混过关。

我以前 把 PostgreSQL 比作“毛坯房” ，讨论的是从开源底座到企业产品还要补哪些东西。这个比喻放到今天仍然适用：选了同一种建筑基础，有人只换了门牌，有人重新设计了管线、空间和承重结构，最后交到用户手里的东西，差别可能很大。

一、PG底座之上还有哪些工作

众所周知， PostgreSQL 是一个由社区驱动的开源数据库，面向社区开发者提供开放的源码、接口和扩展能力。开发者可以用它搭建应用，也可以按自己的需求扩展功能、参与改进。

社区里既有个人开发者，也有长期服务企业的开发者和公司。事务、约束、WAL、复制、恢复等能力，在这些持续投入中不断完善，也构成了 PG 进入企业生产的基础。

不过，社区共同维护的是一个供不同项目使用的通用数据库内核，企业则有各自的应用、部署方式和运行要求。 面向开发者提供通用能力，与围绕具体业务完成企业交付，是不同层面的工作。企业还需要把这些能力组合成适合自己业务的运行方案。

以高可用为例，企业要解决的是：主节点坏了怎么发现，谁来决定切换，网络分区时怎么避免双主，切换以后应用怎么接回来？

PG 提供复制与提升备节点的机制，但 识别主节点故障、通知备节点切换 所需的系统软件，还需要外部组件配合。要把这些机制用于生产，故障处理和部署方案都得有人设计。

类似的差距，还会出现在存量应用兼容、扩展组合、大版本升级，以及特定架构和负载的优化上。有些需求留给周边项目，有些需要修改内核，有些则是企业自己的运行流程。

通用内核提供了基础，企业交付还要处理具体业务中的缺项和限制。这些工作需要落到相应的组件、内核改造和运行流程上，也是评价下游产品时应该具体看的部分。

二、扩展能用只是开始

PG 的扩展生态确实繁荣。空间、向量、调度、审计等能力，都能找到相应项目。做一个新系统的原型时，这种开放性非常方便。

不过，这些扩展并不都是由 PG 核心团队统一开发和发布的，许多项目有各自的维护者、版本节奏和支持范围。开发者可以通过  CREATE EXTENSION 加入所需功能，企业交付还要处理它们组合之后的问题。

一个扩展单独能跑，和它与其他扩展、数据库版本、备份工具、操作系统组合后能够稳定运行，中间还有不少工作。尤其是涉及本地代码、后台进程、共享内存或执行路径的扩展，出问题时，影响范围可能超过一个功能模块。

有些扩展由成熟团队维护，也有些主要依靠个人或小团队。 维护者人数少，不代表技术水平低；但个人愿意回答问题，与企业需要的修复时限和版本支持，仍然是不同的承诺。

PG 提供扩展和更新机制，具体升级脚本、依赖关系、回退方案及组合测试，仍需要相应项目和交付方准备。数据库能启动、应用能连上，也不能证明备份恢复后所有扩展都能正常工作。

内核、扩展和工具由不同团队维护，故障也可能涉及多个项目的交互。说白了，对于采用整套方案的业务方，问题最终需要有人接下来，完成定位、协调修复和验证，而不能只告诉他该去哪个社区提问。

把多个开放项目整合成可维护的产品，本身就有价值。如果还进一步改造了协议、解析、执行或存储路径，就更应该具体看这些研发做了什么。

三、Halo：让原来的应用接得上、跑得对

Halo Database，也就是羲和数据库，在应用兼容方面做了不少工作。它相关的开源项目  openHalo，就是为了让原先面向 MySQL 编写的应用能够在 PostgreSQL 体系上运行，减少应用改造。

这件事听起来像“兼容一下 SQL”，实际涉及的范围要大得多。客户端如何握手和认证，请求和结果如何传输，SQL 如何解析，类型如何转换，错误和会话状态如何返回，都可能影响应用行为。

这些 兼容模块既涉及内核改造，也包含配套的扩展脚本。 改动已经进入数据库内部，不能概括成换个名称、加个管理界面。

企业的存量系统还可能来自不同数据库生态，迁移时要处理的也就不只有 MySQL 这一种兼容需求。商业版 Halo 的  E5 生态引擎采用多模式兼容设计，从通信协议、编译、优化到执行处理不同数据库的兼容需求，功能范围与 openHalo 并不相同。

应用迁过去以后，还要考虑灾备部署。不同位置、不同用途的副本，不一定采用相同的同步确认要求。Halo 的 分组复制允许不同备库组配置不同确认阶段，例如一组等待日志应用完成，另一组等待 WAL 落盘。

分组复制把不同副本的确认要求放进同一次提交中处理。不同确认阶段会影响事务需要等待多久，具体采用哪种组合，仍要结合链路时延和实际写入负载。

对企业来说，这些改造值不值，最终还得看迁移和运行成本。 协议接通之后，应用语义、事务行为和故障路径仍要验证，兼容目标不能自动变成零改造承诺。

四、IvorySQL：存储过程也得有地方放

如果原来的系统用了大量 Oracle 存储过程和 Package，迁移工作又会换一种难法。

Package 可以把过程、函数、变量、游标和异常等组织在一起。有些应用的业务逻辑就放在这里，迁移时无法只搬数据、改几个函数名。

要保留这些业务逻辑，目标数据库就得处理原有的语言规则和对象结构，兼容改造也就需要从 SQL 延伸到过程语言。

IvorySQL保留 PG 的解析路径，增加 Oracle 风格的词法和语法分析，并根据兼容模式选择入口。过程语言方面，则在 PL/pgSQL 基础上发展了 PL/iSQL，配合 Oracle 风格的  Package能力。

PG 提供了可以继续研发的基础，Oracle 风格的过程语言和对象能力则需要额外开发。它们有可能减少应用迁移时的重写工作，也增加了下游自己要维护的代码和测试范围。

不过，支持 Package 不等于所有包都可以直接搬过来。异常处理、类型行为、依赖关系，以及实际用到的系统包，都需要对照业务验证。我认为，这类产品的价值要看“具体保留了多少应用行为”，不能只数兼容列表里有多少个名字。

五、PolarDB for PostgreSQL：共享存储牵动的是整个运行路径

兼容改造主要围绕应用入口和行为，架构改造则会进一步改变数据库的运行方式。

PolarDB for PostgreSQL采用共享存储、存算分离的架构。多个计算节点访问共享数据后，每个节点自己的缓存页面该是什么版本，就成了必须处理的问题。

假设主节点更新了一个页面，只读节点的内存里还留着旧版本。即使底层存储共享，内存也不会自动共享，日志回放和页面可见性仍然需要协调。

LogIndex围绕页面建立日志位置索引，让只读节点找到更新某个页面所需的日志，结合后台回放与按需回放处理页面状态。

按页处理日志以后，还需要考虑一次操作涉及多个页面的情况。回放并行化时，这些页面不能因为处理进度不同而出现不一致，因此还需要 mini transaction 锁等机制来协调。

这里改造的是日志分发、缓存管理和恢复路径，共享存储远不止换一个数据目录。用 PG 作为起点，并没有让这些架构问题自动消失。

一写多读和多主写是不同的架构，共享存储也不表示底层没有冗余。它是否比原生 PG 更快，仍要看实际负载。

六、TDSQL PG：从单节点能力走向集群协作

TDSQL PostgreSQL 版（以下简称 TDSQL PG，原 TBase）涉及的改造，更多落在存储、查询执行和集群协作上。它的历史开源版本  TBase基于 Postgres-XL 继续研发，分布式能力既有上游积累，也有后续演进。

以分布式 JOIN 为例，问题已经不只是一个节点能否生成执行计划。数据分散到不同节点以后，需要判断计算在哪里执行、哪些数据需要搬动，以及搬动多少数据才合适。

在 分布式 JOIN中，协调节点根据集群统计信息生成分布式计划，再由数据节点执行，并通过 Data Redistribution 完成节点间的数据交换。

这类工作直接影响性能：分布式执行计划选得不好，原本可以在本地过滤的数据就可能先被大量传走。跨节点事务还涉及全局事务管理、提交协调与故障后的处理，不能靠多启动几个 PG 实例就自动获得。

集群协作之外，事务处理与分析查询的访问方式也有差别，对存储组织和执行方式的要求并不相同。TDSQL PG 提供行列混合存储、压缩和向量化执行能力，也支持 集中式主备与分布式两类架构。 行存与列存服务不同访问方式，集中式与分布式服务不同规模和运行要求，选择应当跟着业务走。

七、企业交付需要验证哪些能力

这些研发工作让我很难认同“基于 PG，所以没有技术含量”。但反过来，只要改过内核，就天然拥有企业级成熟度，同样站不住。

有实质技术增量，和具备完整企业交付能力，需要分别验证。

一个兼容功能在示例中能执行，不代表客户原来的应用已经跑通；一种新架构设计得合理，不代表备份、恢复、故障切换和升级路径都经过了充分验证。性能也要放进同一负载、同一资源和明确条件下比较。

我还会追问后续维护：上游出了安全修复，谁来判断下游是否受影响？自有改动与新版本冲突，谁负责继续合并？某个关键扩展停止维护，客户的升级怎么办？

改得越深入，获得的自由可能越大，自己承担的研发和维护责任也越多。 长期能力要看它能否持续修复缺陷、维护兼容范围，并把版本安全地交到用户手里。这些工作没有一次跑分显眼，但决定了企业能不能放心用下去。

总结

我认可 PostgreSQL 作为先进、开放底座的价值，也认可在这个基础上继续做研发的价值。二者并不冲突。

在本文的展示中，Halo/openHalo、IvorySQL、PolarDB for PostgreSQL 和 TDSQL PG 展示了不同方向：应用协议与语义兼容、过程语言、共享存储、分布式执行，以及配套的企业运行能力。它们至少说明， 使用 PG 并不妨碍继续改造数据库，真正要评判的是这些改动解决了什么问题。

PG 本身具备企业生产能力，但开放内核和繁荣扩展，不能替代完整的整合、验证、交付与维护。下游产品的价值也不能仅靠“自主研发”几个字证明，需要拿出具体机制和可验证的结果。

来源应该讲清，贡献应该承认，交付能力应该验证。既不因为用了开源就一概否定，也不因为增加了功能就放松企业选型的要求。

老规矩，知道写了些啥。