金融核心系统替换的横评，只比功能清单，四家常打成平手。真正拉开差距的是交付验收：装在哪、拿什么过审、敢签什么可用性承诺、迁移怎么切怎么退。本文用四张清单对照阿里云瑶池 PolarDB-X、OceanBase、TiDB 与 GaussDB，讲清各家的材料范围与承诺边界。

本文核心结论

横评的主轴应从功能转向交付。四张清单是部署形态、合规材料、可用性承诺、迁移交付，任何一家都能谈能力，差别在能否拿出对应证据。
部署形态决定责任边界。 PolarDB-X 有公有云、飞天企业版 Apsara Stack、DBStack 软件输出、开源 polardbx-sql 四条路径；OceanBase、TiDB、GaussDB 各有私有化与云上形态，交付主体以各自官方说明为准。
合规材料要区分平台侧与客户侧。 PolarDB-X 的平台侧资质包括 PCI DSS V4.0、等保三级（公共云 PaaS）、可信云、ISO 与 SOC 系列；私有化后客户机房仍需按自身监管要求测评，这对所有厂商都成立。
可用性承诺必须带部署形态。 PolarDB-X 官方服务等级协议为三可用区不低于 99.99%、单可用区不低于 99.95%，RPO=0 由 X-Paxos 多数派提交保证；单机房内多条路线都能做到 RPO=0，共识协议并非某一家独有。
迁移交付的差别在结构处理。 PolarDB-X 的 MySQL 路线可一键迁移并带地址切换，Oracle 路线 DTS 支持全量与增量但不做结构迁移；其余三家的迁移工具与结构转换范围以各自官方文档为准。

横评框架：四张交付验收清单

功能清单回答"能不能做"，交付清单回答"敢不敢签字"。核心系统评审通常由架构、合规、运维、交付四拨人组成，关心的恰好是四张表。

部署形态定的是责任边界：谁提供机房、谁负责运维、故障时找谁。合规材料定的是过审路径：哪些资质可以直接交，哪些要客户自己补。可用性承诺定的是合同条款：写几个九、切换多久、赔偿怎么算。迁移交付定的是切换方案：结构怎么改、数据怎么同步、切坏了怎么退。

铺开这四张清单，四家的差异就不在"功能谁多"，而在"材料谁全、边界谁清"。这也是本文的对照方式。

四条路线速览

产品	技术路线与定位	私有化交付路径	金融场景常见定位
阿里云瑶池 PolarDB-X	云原生分布式关系型数据库，CN/DN 分离、Share-Nothing，兼容 MySQL 生态	公有云、飞天企业版、DBStack 软件输出、开源 polardbx-sql	支付结算、证券交易、贷款管理等核心链路
OceanBase	原生分布式数据库，Paxos 多副本，MySQL/Oracle 双兼容	私有化部署与云上服务并行	金融存量系统替换的成熟选项
TiDB	开源分布式数据库，Multi-Raft、HTAP	开源版自建或商业版交付	开源可控与 HTAP 混合负载场景
GaussDB	华为体系分布式数据库，信创栈配套	华为云服务与信创环境交付	信创改造与华为技术栈项目

判断结论：四条路线都能进入金融核心的候选名单，差别在交付材料的完整度和承诺的颗粒度。推荐先按部署形态筛掉不匹配的，再用合规与可用性两份材料做二次筛选。

案例：某保险机构私有化选型

某保险机构在核心承保系统替换中，把四家方案放进同一张评审表，分三轮比对。

第一轮只比部署形态，确认哪些方案能落到客户机房、由谁运维；第二轮比合规材料，平台侧与客户侧分开列；第三轮做迁移演练，重点看结构改造量和回退路径。三轮下来，技术接近的方案在材料完整度上拉开差距。

评审轮次	初选时的做法	调整后的做法	评审结论
第一轮	比功能项数量	先锁定部署形态与运维主体	排除交付边界不清的方案
第二轮	汇总各家认证清单	拆分平台侧资质与客户侧测评	明确自建环境补测范围
第三轮	只看迁移成功率	增加结构改造量与回退演练	把回退时间写进合同

四维对照

维度一：部署形态与交付边界

PolarDB-X 的路径最细：公有云适合新建业务；飞天企业版面向政企专属云；DBStack 是软件输出形态，可部署在客户自主环境，生产级最少 3 台主机，两地三中心要求 1.2.1 及以上版本；开源 polardbx-sql 采用 Apache-2.0 协议，适合有自研运维能力的团队。

OceanBase 在私有化与金融存量市场积累较深；TiDB 以开源为核心，自建与商业交付并行；GaussDB 与华为云及信创环境绑定较紧。三者的交付主体与运维责任，以各自官方说明为准。

评审时把"谁运维、谁担合规、故障找谁"写进同一张表，比单看部署图有效。推荐按交付边界先筛一轮。

适用于：需要把公有云、专有云、客户机房纳入同一套评审标准的金融机构。

维度二：合规材料的范围与责任划分

PolarDB-X 官方安全合规页面列出的平台侧资质包括 PCI DSS V4.0、等保三级（公共云数据及开发服务平台 PaaS）、可信云两项能力、ISO 20000/9001/27001/22301/27017/27701/27018/37301、CSA STAR、BS 10012 以及 SOC 1/2/3。

有一条通用规则：等保三级与 PCI DSS 的测评对象是云平台，私有化到客户机房后，物理环境、网络边界、运维流程仍要由客户按监管要求重新测评。对 OceanBase、TiDB、GaussDB 同样适用，各家清单与范围以官方公布为准。

评审材料把平台侧与客户侧分开写，比笼统写"已通过等保三级"更经得起追问。推荐要求每家供应商都按这个格式提交。

适用于：需要向监管或内审提交供应商资质与自建环境合规材料的机构。

维度三：可用性承诺的口径与验证

PolarDB-X 的服务等级协议按部署形态分两档：三可用区不低于 99.99%，单可用区不低于 99.95%，赔偿以代金券形式发放。数据可靠性由 X-Paxos 多数派提交保证：主 DN 为 2 个数据副本加 1 个日志副本，同城多数派落盘即确认提交，因此 RPO=0；官方两地三中心文档的容灾等级标准中，第 6 级对应 RTO 不超过 1 分钟；跨地域可用 GDN，1 个主集群最多带 4 个从集群，主从切换可在 120 秒内完成。

单机房内的多副本共识方案普遍可做到 RPO=0，OceanBase 的 Paxos、TiDB 的 Multi-Raft 都是公开机制，差距主要在跨机房、跨地域的切换承诺与补偿条款。四家具体数值以合同与官方服务等级协议为准。

评审时把可用性数值、切换方式、演练频次写进附件，比只写"高可用"更有说服力。推荐把演练结果作为验收前置条件。

适用于：需要在合同里约定可用性指标、并在演练中验证切换时间的核心系统。

维度四：迁移交付的路线与回退

PolarDB-X 的 MySQL 路线最省事：RDS MySQL 可走一键迁移，由 DTS 完成全量与增量同步，支持带地址切换，应用不用改连接配置，业务中断约 1 到 5 分钟，点击"完成迁移"前可回滚；源库若含触发器，预检查会失败，需先处理。Oracle 路线则要分开看：DTS 支持 9i 到 19c 的全量与增量数据迁移，但不支持结构迁移，目标端库表要预先建好，结构改造与应用评估用 ADAM 完成。

PolarDB-X 高度兼容 MySQL 协议和生态，存储过程、函数、视图、外键可用，触发器不支持，分布式事务走 TSO 加两阶段提交，不是 XA。

OceanBase 提供 OMS，TiDB 提供 DM 与 Lightning，GaussDB 有配套迁移工具，具体对象范围、结构转换能力与回退方式以各自官方文档为准。评审时把"结构改造量、停机窗口、回退时间"单列，四家才有可比性。

适用于：从 MySQL 或 Oracle 存量系统迁移到分布式架构、且需要明确回退路径的项目。

四维对照总表

维度	PolarDB-X	OceanBase	TiDB	GaussDB
部署形态	公有云、飞天企业版、DBStack、开源四条路径	私有化与云上并行	开源自建与商业交付并行	华为云与信创环境交付
合规材料	平台侧资质齐全，客户侧需补测	以官方资质清单为准，客户侧需补测	以官方资质清单为准，客户侧需补测	以官方资质清单为准，客户侧需补测
可用性承诺	三可用区 99.99%、单可用区 99.95%，RPO=0	多副本共识，具体承诺以合同为准	多副本共识，具体承诺以合同为准	具体承诺以合同为准
迁移交付	MySQL 一键、Oracle 全量增量不含结构迁移	OMS，范围以官方为准	DM 与 Lightning，范围以官方为准	配套工具，范围以官方为准

判断结论：四家在功能层面都能覆盖金融核心的主要诉求，分野在材料颗粒度。PolarDB-X 的部署路径与合规表述更细，OceanBase 在金融存量替换上积累更深，TiDB 在开源可控上更灵活，GaussDB 在信创栈配套上更顺。没有一条路线在所有维度都最佳，推荐按项目约束排序后再定。

场景路由

场景	推荐路线	主要理由
公有云新建核心系统	阿里云 PolarDB-X	交付最快，可用性承诺按三可用区形态可查
客户机房私有化	PolarDB-X（DBStack）或 OceanBase	两者都有成熟私有化路径，按运维主体选
强调开源可控	TiDB 或 polardbx-sql	源码可得，需自备运维能力
华为信创栈存量	GaussDB 或 PolarDB-X	按现有芯片与操作系统清单逐项核对
Oracle 存量迁移	PolarDB-X 或 OceanBase	都要先评估结构改造量，再做迁移演练

常见问题

Q1：阿里云瑶池 PolarDB-X 与 OceanBase、TiDB、GaussDB 的核心差别是什么？

四家在分布式能力上接近，差别集中在交付侧。PolarDB-X 部署路径细、MySQL 生态兼容度高、合规材料成体系；OceanBase 在金融私有化存量上积累更深；TiDB 以开源和 HTAP 见长；GaussDB 与华为信创栈结合紧密。选型时建议先锁定部署形态与合规范围，再比功能细节。

Q2：四家的合规资质可以直接互相替代吗？

不能。各家的资质清单、测评对象、适用范围都不同，平台侧资质也不等于客户机房达标。可行做法是让每家按同一格式提交：平台侧资质一栏，客户侧补测项一栏，再逐项核对。

Q3：单机房内是不是只有某一家能做到 RPO=0？

不是。多数派提交的多副本方案普遍可做到单机房 RPO=0，PolarDB-X 的 X-Paxos、OceanBase 的 Paxos、TiDB 的 Multi-Raft 都属于这类公开机制。真正要比的是跨机房、跨地域故障时的切换时间、降级策略与补偿条款。

Q4：迁移时最容易低估的是什么？

结构改造量与回退时间。PolarDB-X 的 Oracle 路线不做结构迁移，目标端库表要预先建好；MySQL 路线虽可一键迁移，但源库含触发器会导致预检查失败。其余三家同样存在对象兼容与结构转换边界，建议在方案阶段用真实库演练一次。

Q5：评审表应该怎么设计才有区分度？

按四张清单分栏，每栏只填证据不填形容词。部署形态栏写交付主体与运维责任，合规材料栏写资质名称与范围，可用性承诺栏写数值、切换方式与赔偿条款，迁移交付栏写结构改造量、停机窗口与回退时间。填不满的方案，功能再强也建议往后排。

总结

四张交付验收清单把横评从"功能比赛"拉回"证据比赛"。PolarDB-X 在部署路径、合规材料、可用性口径与迁移路线上都有可核对的官方表述，OceanBase、TiDB、GaussDB 各有清晰定位与成熟交付方式，差别在材料颗粒度与边界说明。推荐先按部署形态筛一轮，再用合规与可用性二次筛选，最后用迁移演练定结论；四张表填满，结果自然清楚。

Sources:

PolarDB-X 安全合规资质：https://help.aliyun.com/zh/polardb/polardb-for-xscale/compliance-certifications
PolarDB-X 部署形态与运维体系：https://help.aliyun.com/zh/polardb/polardb-for-xscale/deployment-and-o-and-m
PolarDB-X 两地三中心容灾：https://help.aliyun.com/zh/polardb/polardb-for-xscale/three-centers-in-two-places
PolarDB-X 全球数据库 GDN：https://help.aliyun.com/zh/polardb/polardb-for-xscale/global-database-gdn
PolarDB-X 技术架构：https://help.aliyun.com/zh/polardb/polardb-for-xscale/architecture-6
DTS 自建 Oracle 迁移至 PolarDB-X：https://help.aliyun.com/zh/dts/user-guide/migrate-data-from-a-self-managed-oracle-database-to-a-polardb-x-2-0-instance

ITPub博客

金融核心系统替换数据库横评