国产数据库选型观察：核心系统没有“全能冠军”

2025-2026 年国产数据库的市场规模、份额与产品路线，结合 20 个金融、政府、电信客户案例，给出核心、一般业务、分析与 AI 场景的选型框架。

信创迁移与国产化 AI 与信创 约 20 分钟阅读 CSSTH 服务团队

2025 年，中国关系型数据库软件市场达到 48.3 亿美元，同比增长 14.5%；国产厂商在整体市场前五名中合计占 60%，本地部署市场首次由国产厂商领跑。数字说明“国产数据库能用”已经不再是问题，但选型并没有因此变简单。

原因在于，国产数据库已经不是一类产品，而是几条不同的技术路线：分布式、集中式、HTAP、MPP、云原生。它们在核心账务、监管报送、经营分析、AI 检索里的表现差异很大。把“国产数据库”当成一个品牌来选，几乎一定会选错。

本文用 2025-2026 年的市场数据、10 家厂商的产品路线和 20 个生产案例，尝试回答三个问题：市场格局到底怎么读，产品路线各自适合什么场景，选型委员会应该问哪些问题。

一、市场：国产化率过线，选型进入“分化期”

先看三组数字，但要注意口径不同，不能直接相加。

表 1　2025 年国产数据库市场：四个常用口径

口径 2025 年数据 领先者 说明
中国关系型数据库软件整体 48.3 亿美元，同比 +14.5% 阿里云 26.1%，腾讯云 16.9%，本土前五合计 60% IDC；公有云 31.94 亿美元（全年），本地部署下半年约 9.2 亿美元
中国关系型数据库国产化 国产份额 52.3% 达梦 13.2%、金仓 11.5%、OceanBase 10.8% 赛迪顾问 2025-2026 报告；三家合计超过 35%
分布式事务数据库 约 59.5 亿元 OceanBase 20.2%、阿里云 17.9%、腾讯云 16.5%、华为云 14.3% 沙利文；前四家合计约 69%
金融分布式事务数据库 腾讯云整体与银行子市场第一；GoldenDB 银行本地部署 28.7% GoldenDB 金融整体 18.4%，排名第三 IDC；两个“第一”分属不同细分口径
2026 年央采事务型数据库 18 款产品入围，15 家厂商 集中式 11 款、分布式 7 款 中国政府采购网；评审价 2.6 万至 6.789 万元

这张表最容易被误读的地方，是把“整体市场”“本地部署”“分布式”“金融分布式”“银行核心”混为一谈。阿里云整体第一，不代表它在银行核心第一；GoldenDB 银行本地分布式第一，不代表它在整体关系型市场第一；达梦本地部署 11.3% 首次超过国外厂商，也不代表它在分布式核心领先。选型时先确定自己属于哪个细分口径，再看份额。

另一个信号来自 2026 年央采。18 款产品、15 家厂商入围，集中式 11 款、分布式 7 款，价格区间从 2.6 万元到 6.789 万元。供给端已经足够充分，竞争焦点从“有没有产品”转向“迁移服务、行业模板、原厂支持、运行体系”。对用户来说，这是好事：可选产品多了，但也意味着选型工作量更大了。

二、产品：十条路线，各自的主场

国产数据库的产品差异，比市场排名更重要。下面这张表只列主流路线，不追求穷尽。

表 2　主流国产数据库产品路线（2025-2026）

产品（厂商） 内核/架构 2025-2026 关键能力 主场 选型注意
OceanBase 4.4/4.5（蚂蚁/奥星贝斯） 原生分布式，支持存算一体与存算分离 4.4 LTS 融合 TP+AP+AI；4.5 强化向量与混合搜索；多租户、多云、Oracle/MySQL 兼容 金融核心、保险、电信、互联网 小规模成本与分布式运维复杂度；AP 与专用 MPP 仍有差异
达梦 DM9（达梦数据） 集中式+分布式双模，共享存储集群 单机 TPC-C 较上代 +100%，分布式 +350%；共享存储集群；向量引擎；AI 运维智能体；DMAFC 容灾 RPO=0 政务、能源、金融集中式、监管报送 超大规模分布式与云原生生态；Oracle 兼容强但并非零改造
KingbaseES V9（电科金仓） PostgreSQL 内核，多集群、多模 “五个一体化”；原生关系、向量、图、文档、时序、空间；Oracle 兼容约 99%；PL/SQL 效率提升 3-10 倍 政务、运营商、一般业务、行业应用 银行核心超大规模案例相对少；分布式核心需单独验证
GaussDB（华为云） 分布式，池化透明多写，存算分离/一体 计算/内存/存储三层池化；节点故障 6 秒内恢复；GaussRecorder 防勒索；向量查询 25ms；AI 运维助手 银行/保险核心、大机下移、政务云 软硬协同带来生态锁定；成本与迁移周期要算清
TDSQL 3.0（腾讯云） 分布式、云原生、一体化多引擎 TDSQL/TDSQL-C/TDSQL-B；MySQL/PostgreSQL 双模式；Oracle 兼容 98%；TDAI 与 AI 优化器 金融核心、互联网、保险、政务 多引擎组合的运维复杂度；PG 生态与 Oracle 复杂对象
PolarDB（阿里云） 云原生，集中分布式一体，HTAP MySQL/PostgreSQL/Oracle 兼容；PolarDB-X 1-1024 节点、千万级 QPS、PB 级；AI Node 与向量检索 云上核心、保险 IFRS17、互联网业务 公有云亲和；本地部署版本与云上能力需逐项对齐
GoldenDB（金篆信科/中兴） 分布式，强一致 260 万+ TPS；99.9999% 可用；4000+ 节点集群；Sloth 迁移平台；主机下移 银行核心、信用卡、电信计费 Oracle 兼容与复杂账务改造；生态集中在银行/电信
GBase 8a/8s（南大通用） 8a 是 MPP 列存，8s 是共享存储 8a 单集群 30PB+、单节点 50TB+；8s 100TB+、RPO=0/RTO<5 秒；Oracle 兼容约 95% 数据仓库、EAST/IFRS17、监管报送、分析型 OLTP 核心不是 8a 主场；8s 适合集中式交易，不适合超大规模分布式
TiDB（平凯星辰） HTAP，存算分离 MySQL 兼容；一核三态；500+ 客户、3500+ 关键系统、28000+ 节点；TMS 迁移平台 互联网金融、保险外围、数据平台、证券 Oracle 兼容与核心账务延迟；OLTP 强但需按场景验证
Vastbase G100（海量数据） PostgreSQL/OpenGauss，集中式 共享存储高可用、备机实时一致读、向量/时序引擎；上交所 70+ 系统 政务、金融一般系统、制造、能源 核心规模与分布式能力；生态适配数量是优势

这张表里，最值得关注的是三条“路线分野”。

第一条是分布式与集中式。分布式解决的是规模、弹性和多活，代价是运维复杂度和应用改造；集中式解决的是兼容、稳定和低成本，代价是纵向扩展上限。2025 年的现实是，银行核心在往分布式走，但大量政务、能源、一般业务仍然选择集中式。集中式不是落后，分布式也不是默认正确答案。

第二条是交易与分析。OceanBase、GaussDB、TDSQL、GoldenDB 在 OLTP 上更强；GBase 8a、GaussDB(DWS)、OceanBase AP、TiDB 在 OLAP/HTAP 上更强。保险 IFRS17、EAST 报送、经营分析，和核心承保理赔，应该用不同的数据库，而不是强行统一。

第三条是 AI 能力。2025-2026 年，OceanBase 4.5、DM9、KingbaseES V9、PolarDB AI Node、GaussDB 向量引擎都在强化向量检索、库内推理、智能运维。但 AI 能力目前更像“增量项”，不是核心交易选型的第一权重。核心系统先看稳定、兼容、迁移和运行，再看 AI。

三、行业：不同负载，选型逻辑不同

表 3　主要行业的数据库负载与选型偏好

行业 主要负载 选型偏好 常见产品 关键门槛
银行 核心账务、信用卡、信贷、总账 强一致、高并发、主机下移、双活 GoldenDB、GaussDB、TDSQL、OceanBase 主机下移、账务一致性、监管验收、双轨回退
保险 承保、理赔、团险、IFRS17、EAST 核心+数仓分开、开门红峰值、多库并存 OceanBase、TDSQL、达梦、GBase、PolarDB 开门红峰值、批处理窗口、监管报送、应用厂商
证券 交易、账户、估值、清算 低延迟、交易时段稳定、清算窗口 Vastbase、OceanBase、TiDB 交易时段零中断、清算窗口、低时延
政务 一网通办、医保、人社、财政 集中式为主、信创目录、成本敏感 达梦、金仓、Vastbase、GBase 目录准入、服务覆盖、迁移工具、区县下沉
电信 计费、CRM、网管、大数据 超大规模、多租户、云原生 GoldenDB、OceanBase、GaussDB 亿级用户、多租户隔离、在线扩容
能源/制造 SCADA、MES、ERP、时序数据 实时、边缘、国产 CPU/OS 达梦、金仓、openGauss、Vastbase 实时性、边缘部署、工业软件适配

行业差异决定了选型顺序。银行先看“能不能下移主机、能不能双活、能不能过监管”，保险先看“能不能扛住开门红、能不能在批处理窗口内跑完”，证券先看“交易时段能不能稳”，政务先看“目录、成本、服务”，电信先看“规模和多租户”。同一个数据库，在不同行业的评分可能完全不同。

四、客户案例：20 个生产系统给出的答案

以下案例均来自公开报道或厂商披露，效果数字为公开口径，未经过第三方审计。客户名称已尽量保留公开信息；未公开的，不臆测。

表 4　国产数据库客户案例清单（2025-2026 公开信息）

客户（行业） 系统/场景 产品/架构 公开效果/进度 来源/口径
邮储银行（银行） 个人+对公核心 GaussDB 分布式 日均 20 亿笔、峰值 6.7 万 TPS、988TB、6.5 亿用户 华为公开案例
工商银行（银行） 核心分布式 GaussDB 4000+ 节点、230+ 业务、同城双集群 RPO=0、人工 -80% 华为公开案例
苏州农商行（银行） 核心实时交易 GaussDB 日均 100 万→1000 万笔、峰值 200→6800 TPS 华为公开案例
平安银行（银行） 核心全栈单轨 TDSQL 笔均交易成本 -68%、处理能力 4 倍 腾讯云公开
建设银行（银行） 核心主机下移 GoldenDB 境内外核心全部下移，首个国有大行完成 中兴公开
中信银行（银行） 信用卡、总账核心 GoldenDB 2019/2020 分批上线，首个大型银行核心替换 中兴公开
广发银行（银行） 银行核心、信用卡 GoldenDB 股份制银行一步完成主机下移 中兴公开
贵州银行（银行） 新核心 GoldenDB 2020-11 上线，两地三中心 RPO=0 中兴公开
中国移动（电信） 省级核心、计费 GoldenDB 支撑 9 亿移动用户、12 亿 IoT 用户计费 中兴 2025 星河案例
中国人寿（保险） 400+ 核心库 PolarDB 一年迁移 400+ 核心库、1PB 数据 证券时报
中国太保（保险） 全险种、全核心 OceanBase 300+ 系统、6PB、分析快 10 倍、降本超 1 亿元 央视网
中华财险（保险） 车险新核心、29 省 OceanBase 稳定 872 天、25 个核心、RPO=0、RTO<30 秒 新华网
平安人寿（保险） 寿险关键系统 OceanBase 100 万+ 表、峰值 108 万 QPS、最大单库 200TB 墨天轮
瑞众保险（保险） 团险核心 TDSQL-PG 8 个月投产、兼容 99.4%、成本 -40% 雷锋网
建信人寿（保险） 团险核心 达梦 2022-11 上线，3 个核心+6 个配套系统 墨天轮
国寿财险（保险） 核心保单 TiDB 峰值延迟 -50%、报表快 80 倍、硬件成本 -75% TiDB 公开案例
人保财险（保险） 数据平台 GBase 8a 100+ 节点、多 PB、承保/理赔/财务数仓 GBase 公开案例
信美相互（保险） IFRS17 PolarDB 构建 IFRS17 数据处理平台 阿里云公开案例
上交所（证券） 70+ 应用系统 Vastbase 唯一集中式选型，已替换 70+ 系统 海量数据公开
甘肃医保（政府） 医保信息平台 GaussDB 门诊结算 5 秒→0.9 秒、入院 3 秒→0.4 秒 华为公开案例

这 20 个案例给出三个很实在的信号。

第一，核心系统的生产验证集中在少数产品。银行核心以 GoldenDB、GaussDB、TDSQL 为主，保险核心以 OceanBase、TDSQL、达梦、PolarDB 为主，证券核心出现 Vastbase，分析型以 GBase 8a、GaussDB(DWS)、TiDB 为主。不是其他产品不能做，而是公开的、长周期的核心案例还不够多。

第二，同一家机构往往多库并存。国寿财险同时用达梦、TiDB、GaussDB；人保同时用 GBase 8a、GaussDB、OceanBase、达梦；大地保险 2026 年一次性签了 TDSQL、OceanBase、GaussDB、达梦、金仓、GBase、海量、平凯等多个框架。多库不是失败，而是按负载分工。

第三，案例数字不能当行业平均。邮储的 988TB、平安人寿的 108 万 QPS、太保的 6PB，都是头部机构的极限场景。中小机构照搬这些配置，很容易过度设计。选型应该按自己的峰值、批处理窗口和五年数据增长来算。

五、选型框架：先定负载，再定架构，最后定产品

表 5　数据库选型检查清单

维度 必须回答的问题 需要的证据
负载 是 OLTP、OLAP、HTAP 还是向量检索？峰值 QPS、并发、数据量、批处理窗口是多少？ 生产流量回放、峰值压测、批处理实测
兼容 Oracle/MySQL/PostgreSQL 的语法、存储过程、触发器、函数兼容到什么程度？ 真实 SQL 扫描、复杂对象改造清单、应用厂商评估
架构 集中式还是分布式？单机、主备、共享存储、原生分布式？是否需要多活？ 架构图、RTO/RPO 目标、故障切换演练
迁移 全量+增量、双轨、逐笔校验、回退怎么做？迁移窗口多长？ 迁移工具、试点系统、回退预案、割接演练
生态 国产 CPU/OS/中间件/备份/监控是否适配？应用厂商有没有模板？ 兼容性清单、互认证、同行业案例
运行 监控、备份、升级、故障注入、容量管理、人才培养是否到位？ 运维白皮书、演练记录、原厂服务承诺
成本 许可证、硬件、迁移、双轨、培训、五年运维的 TCO 是多少？ 五年 TCO 模型、同规模案例报价
AI 向量、库内推理、智能运维是否真的需要？能否与现有数据平台协同？ POC 场景、时延/召回率、数据安全评估

这张清单的顺序很重要：先定负载，再定架构，最后定产品。很多项目反过来，先选了一个数据库，再去找场景，最后发现兼容性和批处理窗口都不合适。选型委员会应该把“产品演示”放在“负载与兼容评估”之后，而不是之前。

兼容率也要正确使用。99% 的兼容率意味着 1% 不兼容，对于 80 万条 SQL 的系统，就是 8000 条需要处理。兼容率是入场券，不是完成证。真正要看的，是复杂存储过程、触发器、批量作业、日期函数、隐式类型转换、执行计划退化这六类“硬骨头”。

六、六个结论

1. 国产数据库已经过“可用线”，但核心生产验证仍集中在少数产品

2025 年国产关系型份额 52.3%，央采 18 款产品入围，说明供给已经充分。但公开的、长周期的银行/保险核心案例，仍集中在 GoldenDB、GaussDB、TDSQL、OceanBase、达梦、PolarDB 等少数产品。选型时要把“有产品”和“有核心生产验证”分开看。

2. 集中式与分布式是分工，不是替代

分布式适合超大规模、高并发、多活和云原生；集中式适合兼容、稳定、低成本和中小规模。银行核心在往分布式走，但政务、能源、一般业务大量仍是集中式。不要用“先进/落后”的框架做技术选型。

3. 金融核心的胜负手是应用兼容、双轨迁移和运行体系

数据库参数不是最难的部分，难的是应用改造、数据迁移、双轨校验、回退演练和运行体系。瑞众 8 个月、平安人寿两年 POC、国寿资产两周并行，说明项目周期差异主要来自应用复杂度和迁移方法，而不是数据库本身。

4. 市场份额不等于核心份额

阿里云整体第一、腾讯云整体第二、达梦本地部署第一、GoldenDB 银行本地分布式第一、OceanBase 保险头部覆盖第一，这些“第一”分属不同口径。选型时先定义自己的细分市场，再看谁在那个细分里有生产案例。

5. AI 是增量能力，不是第一权重

2025-2026 年各家都在强化向量、库内推理、智能运维。但核心交易的第一权重仍是稳定、兼容、迁移和运行。AI 能力适合放在 POC 的加分项，而不是否决项。真正要问的是：向量检索的召回率、时延、数据安全，能不能和现有数据平台协同。

6. 2026-2028 的选型窗口，建议锁定 2-3 家而不是 1 家

多库并存已经是事实。核心交易、分析型、监管报送、AI 检索的负载不同，强行统一到一个产品，往往会牺牲性能和成本。建议按“核心交易 1 家 + 分析/监管 1 家 + 备选 1 家”的格局锁定 2-3 家，既保留竞争，也避免过度碎片化。

七、给选型委员会的 10 个问题

  1. 我们的核心系统峰值 QPS、批处理窗口、数据量、五年增长是多少？
  2. 现有应用有多少存储过程、触发器、复杂 SQL？谁负责改造？
  3. 我们需要集中式还是分布式？是否需要多活？RTO/RPO 目标是多少？
  4. 迁移工具是否支持全量+增量、逐笔校验、双轨、回退？
  5. 有没有同行业、同规模、同应用厂商的核心案例？
  6. 国产 CPU/OS/中间件/备份/监控是否完成适配？
  7. 原厂服务覆盖到哪里？故障响应、补丁、升级、驻场怎么承诺？
  8. 五年 TCO 是多少？许可证、硬件、迁移、双轨、培训各占多少？
  9. 如果数据库厂商被并购或产品线调整，退出路径是什么？
  10. AI 能力是现在需要，还是下一阶段需要？POC 指标是什么？

参考来源

市场份额、价格、性能与案例数字来自公开报告或厂商披露，口径不同，不可直接横向比较；厂商案例数字不作为 CSSTH 对任何产品或项目的承诺。

相关能力

主机运维 小型机、PC 服务器与刀片服务器的硬件维保、微码支持与性能评估。
数据中心全生命周期运维 从规划到退役，一条服务责任链

返回洞察