国产关系型数据库生态深度分析
本文完成于2026年3月3号。
有很多人问过我："国产数据库该怎么选？"
前几年我刚入棋局，确实看不太清，但亲身经历了这几年国产数据库在各个战场上的厮杀后，我逐渐有了一些自己的思考。这篇文章，算是我对国产数据库生态的阶段性总结。
免责声明：本文仅代表个人观点，与任何公司无关。文中的分析和建议仅供参考，不构成任何投资或选型建议。
一、商业形态：基础设施与平台绑定的本质
历史视角下的商业模式演变
数据库管理系统(RDBMS)的商业模式，从诞生之初就与运行平台紧密绑定：
- 早期硬件绑定阶段：RDBMS最初作为大型机硬件的附属组件存在，比如teradata的DBC、IBM的System R，买硬件送数据库，软件价值依附于硬件。
- 独立软件形态阶段：Oracle等厂商将数据库作为独立软件销售，但很快又通过Exadata等一体机实现了新的绑定——用专用硬件(虽然本质上是通用硬件加专用软件)优化数据库性能，重新把软件和硬件绑在一起卖。
- 云时代的再绑定：云数据库RDS打破了传统硬件绑定，却形成了新的云平台绑定模式。用户一旦选择了某家云厂商的数据库服务，再迁移到其他平台的成本就会变得极高。
国产数据库的生存之道
从商业可持续性角度来看，国产数据库目前主要有两种选择：
- 云数据库模式：阿里云、腾讯云、华为云等云厂商的数据库服务，本质是"卖云附赠数据库"，用云平台的流量优势带动数据库销售。
- 数据库一体机模式：提供软硬件一体化解决方案，便于大公司追责。这种模式对技术实力要求很高，因为需要自己搞定硬件优化和软件适配。
华为是国内唯一同时拥有云服务和服务器硬件能力的厂商（这里的"硬件能力"指的是具备芯片级生产能力，不是那种攒服务器的OEM厂商）。不过客观地说，国产服务器整体性能仍落后于国际水平。大公司之所以倾向于选择一体化解决方案，主要是为了避免多供应商责任推诿的问题——出了问题找谁？找一家总比找两家三家要方便。
说个暴论：仅有纯软形态的数据库厂商，无法满足对核心系统极致性能的要求。（证券、期货交易就是典型例子，不断对性能优化，甚至微秒级别的延时也在扣，会员服务器和交易所服务器放一个机房，连网线长度都考虑进去了，网线短1米就比别人快一点。相较于网络延迟，服务器的软硬件延迟更有提升空间。）
不过在当下算力资源极度紧张的情况下，服务器价格虚高不下，买服务器或者买一体机时，总会要考虑成本问题，需要几台机器才能跑数据库。
二、分布式数据库的全球布局
三大分布式数据库代表
- OceanBase：蚂蚁集团旗下的明星产品，支持阿里云部署，拥有全球开源社区。在双11的极端流量考验下证明了自己的实力。
- TiDB：PingCAP公司的拳头产品，支持全球主流云平台一键部署，生态覆盖广泛。可以说是国产分布式数据库中全球化做得最好的。
- GoldenDB：中兴通讯旗下金篆信科自主研发，已在工商银行等多家金融机构核心系统中得到应用。不过目前没有云服务支持，主要走传统软件销售路线，仅布局国内。
当然还有其他的分布式数据库，这里只列出这三家是因为他们的产品线集中在分布式上，不像其他家既有集中式又有分布式。
分布式数据库的生态优势
尽管集中式数据库仍能满足大部分线下业务需求，但互联网业务的快速扩张推动了分布式数据库的发展。OceanBase和TiDB通过开源社区建设，已经实现了全球布局，在国际云平台上拥有广泛的部署支持。这一点很重要，意味着它们已经不再局限于国内市场。
慎重选用分布式
我必须强调：绝大多数场景使用集中式就够了，改用分布式反而可能会引入复杂架构的运维压力。传统应用不经大量改造直接使用分布式，会是巨大的灾难。我见过太多公司为了赶时髦上分布式，结果开发和运维成本飙升，而且经常出现性能反而不如之前的集中式数据库。
三、老四家：政企市场的中坚力量
四家基本情况
- 达梦：纯自研，归属于中电子集团，市场表现强劲。在央企和金融行业拥有大量客户。
- 金仓：基于PG魔改，归属于中电科集团，政务市场优势明显。很多政府部门的核心系统都在用金仓。
- 南大通用：早期购买了informix源码进行自研，但现在已经转向openGauss生态。
- 神舟通用：原本是基于PG魔改，但现在也转向了openGauss生态。
核心竞争力分析
前两家凭借央企背景和早期市场布局，在政企军工市场占据了稳固地位。后两家转向openGauss生态的原因，我没有做过深入调查，不好妄加评论。是原有业务不佳，想通过新生态寻找突破口？还是原有业务不错，仍有余力去通过新生态实现业务增量？我没有发言权。
不过可以肯定的是，这类厂商的核心优势往往体现在生态合作与资源整合能力上，能够快速响应特定行业客户的需求。但在技术研发投入和产品迭代速度上，确实与大型互联网厂商存在一定差距。
四、openGauss生态：最多厂商参与研发的国产数据库
技术起源与发展
openGauss源自华为GaussDB早期内核，基于PostgreSQL 9.2.4+PGXC发展而来，现在已经完全独立演进。这个生态保留了解决原生PG三大核心问题的能力：
- ustore存储引擎：解决了PG在大表场景下的性能问题。
- 64位XID支持：解决了PG的XID回绕问题，提升了系统稳定性。
- 线程模型优化：提升了并发处理能力。
生态现状
截至2025年，openGauss已经有24家公司推出了32个认证商业发行版，主要包括：
- Vastbase G100（海量数据）
- MogDB（云和恩墨）
- GBase 8C（南大通用）
- 神通（神舟通用）
这些厂商同时也是openGauss内核代码贡献最多的非华为厂商。不过需要注意的是，目前openGauss和GaussDB内核差异已经很大了，部分相同功能在两个库上的内核实现完全不同。虽然有这么多厂商参与，但实际上目前的模式主要还是以任务分配为主，不像其他开源社区大多是开发者主动提交新特性。
在openGauss的众发行版中，除了以上4家主要的，中移动的磐维也得提一下，这款产品可谓是集各家之长所作，融合了多家其他openGauss发行版各自的优势。
另外，根据openGauss官方的贡献看板数据来看，目前在openGauss社区的内核代码上，主要的厂商贡献量均在逐渐下滑，远不如前几年，而华为公司参与的占比却在逐渐提升。
五、开源生态：不完全的开放
开源现状分析
- 部分开源：TiDB、OceanBase、Polardb-PG、GaussDB等，都只开放了部分代码。核心功能闭源，外围功能开源，这是国内厂商常见的开源策略。
- 生态独立性：openGauss和OceanBase拥有独立的开源生态，而IvorySQL则与PG社区高度绑定。这种绑定有利有弊，好处是可以借助PG社区的力量，坏处是容易受到PG社区的影响，无法对内核框架进行大刀阔斧的修改。
开源社区影响力
TiDB和OceanBase通过全球开源社区建设，吸引了大量海外开发者参与，实现了全球布局。在国际云平台上拥有广泛的部署支持，这一点是其他国产数据库很难比拟的。IvorySQL凭借对PG社区的贡献，在国际上获得了较高认可度，算是国产数据库在PG生态中的代表。
六、Oracle兼容性：国产数据库的必争之地
主要兼容产品对比
| 数据库 | 兼容策略 | 优势 | 不足 |
|---|---|---|---|
| 达梦 | 早期布局，积累大量场景 | 兼容性好，起步早，语法执行成功率高。很多用户反映，迁移过去后几乎不需要做太多改动。 | 部分功能表现行为与Oracle不完全一致，需要额外适配。比如某些函数或存储过程的执行结果可能会有差异。 |
| 金仓 | 基于PG生态，适配难度低 | PG基础好，语法适配成本低。因为PG本身就和Oracle有一定的相似性，所以兼容性做得比较轻松。 | PG存储引擎与Oracle存在本质差异。容易遇到事务相关的不兼容性，在内存和数据格式上的设计也会影响代码执行表现。 |
| OceanBase | 从MySQL兼容转向Oracle兼容 | 技术实力强，兼容性提升快。凭借蚂蚁集团的技术积累，在兼容性上进步神速。 | 分布式架构导致部分妥协。为了实现分布式，不得不牺牲一些Oracle的特性。 |
| 崖山 | 原生设计匹配Oracle | 架构匹配度高，运维经验复用。从设计之初就对标Oracle，所以运维人员可以复用之前的Oracle运维经验。 | 入场晚，需要更多实战打磨。虽然架构很好，但缺乏大规模场景的验证，还需要时间积累。 |
潜在风险
所有Oracle兼容产品都面临知识产权风险，尤其是通过逆向工程实现的兼容性，可能会引发法律纠纷。毕竟Oracle在专利上做了很多布局，想要绕过这些专利并不容易。
现在有AI，对于应用代码的兼容性改造，能节省很多工作量。不过尽管AI技术降低了应用改造难度，央国企核心系统对AI开发的接受度仍较低。很多老系统还是习惯用传统的开发方式，对AI生成的代码持怀疑态度。
七、信创与安可：国产数据库的入场券
基本概念解析
- 信创：是一种行为，即信息化创新，推动国产替代。简单来说，就是要把国外的产品换成国内的或者自研的。
- 安可：安全可靠产品认证，需要通过国测。这是进入政企市场的必备条件。（被误称为"信创名单"）
- 国测：中国信息安全评测中心和国家保密科技测评中心联合举办的测试。只有通过了这个测试，才能拿到安可认证。这个测试不仅会测产品本身，甚至还会对研发人员进行技能测试，还要审查研发流程、公司的风险承担能力等供应方面的项目。
- 可信：特定功能的专项评测。主要评估对应产品是否具备特定功能，一款产品是可以同时获得很多个不同功能的可信认证的，因此这并不代表有可信认证就符合政企要求。
现在有非常多的发信创认证证书或者可信认证证书的机构，这些机构发的这些证书并不代表具备安可认证。
信创化并不是必须使用安可数据库，安可认证只对"关基单位"有强制性，对于非"关基单位"，没有安可认证的国产数据库也是可以选择的。但是既然有国家给的名单，就算不强制，大家也通常会选通过了安可的数据库，毕竟这后面多了个国家的背书。因此如果没有挤进这个安可，在信创赛道上就会被远远甩在后面。
认证现状
截至2025年底，已经有三批数据库通过了安可测评。对于国产数据库厂商而言，安可认证已经成为市场准入的必要条件。除非能在易用性或其他赛道上建立绝对优势，否则没有安可认证，基本就和政企市场无缘了。
安全可靠测评结果公告（2023年第1号）
附表三、集中式数据库
| 序号 | 产品名称 | 送测单位 | 安全可靠等级 |
|---|---|---|---|
| 1 | 达梦数据库管理系统 V8.4 | 武汉达梦数据库股份有限公司 | I 级 |
| 2 | PolarDB V2.0 | 阿里云计算有限公司 | I 级 |
| 3 | TDSQL 关系型数据库管理系统软件 V8.0 | 腾讯云计算（北京）有限责任公司 | I 级 |
| 4 | 瀚高安全版数据库系统 V4.5 | 瀚高基础软件股份有限公司 | I 级 |
| 5 | 虚谷数据库管理系统 V11.0 | 成都虚谷伟业科技有限公司 | I 级 |
| 6 | 南大通用安全数据库管理系统 GBase 8s V8.8 | 天津南大通用数据技术股份有限公司 | I 级 |
| 7 | 海盒通用数据库管理系统（ SeaboxSQL ） V11.5 | 北京东方金信科技股份有限公司 | I 级 |
| 8 | 金仓 数据库管理系统 KingbaseES V8 | 北京人大金仓信息技术股份有限公司 | I 级 |
| 9 | 海量数据库 G100 管理系统 V2.2 | 北京海量数据技术股份有限公司 | I 级 |
| 10 | 万里安全数据库软件 V1.0 | 北京万里开源软件有限公司 | I 级 |
| 11 | 优炫数据库管理系统 V2.1 | 北京优炫软件股份有限公司 | I 级 |
安全可靠测评结果公告（2024年第2号）
附表一、数据库（同一等级按产品名称首字笔画为序排列）
（一）集中式数据库
| 序号 | 产品名称 | 送测单位 | 安全可靠等级 |
|---|---|---|---|
| 1 | GaussDB V2.0(集中式版) | 华为云计算技术有限公司 | Ⅱ级 |
| 2 | 金仓数据库管理系统V9 | 中电科金仓（北京）科技股份有限公司 | I级 |
| 3 | 神通数据库管理系统V7.0 | 天津神舟通用数据技术有限公司 | I级 |
| 4 | 海量数据库管理系统G100[简称：Vastbase G100] V3.0 | 北京海量数据技术股份有限公司 | I级 |
| 5 | 瀚高数据库管理系统V9.0 | 瀚高基础软件股份有限公司 | I级 |
| 6 | TaurusDB V2.0 | 华为云计算技术有限公司 | I级 |
（二）分布式数据库
| 序号 | 产品名称 | 送测单位 | 安全可靠等级 |
|---|---|---|---|
| 1 | 平凯数据库企业版软件 V7.1 | 平凯星辰（北京）科技有限公司 | I级 |
| 2 | 达梦数据库管理系统（分布式版）[简称：DMDPC] V8.4 | 武汉达梦数据库股份有限公司 | I级 |
| 3 | 阿里云PolarDB数据库管理软件（分布式版）V2.0 | 阿里云计算有限公司 | I级 |
| 4 | 金仓分布式HTAP数据库集群软件V3 | 中电科金仓（北京）科技股份有限公司 | I级 |
| 5 | 南大通用大规模分布式并行数据库集群系统[简称：GBase 8a MPP Cluster] V9 | 天津南大通用数据技术有限公司 | I级 |
| 6 | 神通数据库管理系统（MPP集群版）V7.0 | 天津神舟通用数据技术有限公司 | I级 |
| 7 | 虚谷数据库管理系统 V12.0 | 成都虚谷伟业科技有限公司 | I级 |
| 8 | 腾讯云分布式数据库 TDSQL管理系统 V10.3 | 腾讯云计算（北京）有限责任公司 | I级 |
| 9 | GaussDB V2.0（分布式版） | 华为云计算技术有限公司 | I级 |
| 10 | GoldenDB数据库 V6 | 中兴通讯股份有限公司 | I级 |
| 11 | OceanBase数据库软件 V4 | 北京奥星贝斯科技有限公司 | I级 |
安全可靠测评结果公告（2025年第2号）
附表一、数据库（同一等级按产品名称首字笔画为序排列）
（一）集中式数据库
| 序号 | 产品名称 | 送测单位 | 安全可靠等级 |
|---|---|---|---|
| 1 | 大云海山数据库（ He3DB for PostgreSQL V2.0） | 中移（苏州）软件技术有限公司 | I级 |
| 2 | 神通数据库管理系统 V8.0 | 天津神舟通用数据技术有限公司 | I级 |
| 3 | 崖山数据库管理系统 V23 | 深圳计算科学研究院 | I级 |
另外注意，评测结果里的版本号，并不一定会和实际使用的版本具备一一对应关系。只要能通过测试，厂商会有各种手段来使没有送测的产品介质也使用这个版本号，而且还能有"合规"解释，具体就不细说了，懂的都懂。
八、数据库品牌的复杂性
多产品线策略
很多数据库厂商都采用了多产品线策略，同一个品牌下可能有多个不同的产品：
- GaussDB：包含DWS(MPP)、T(100 ,事务性)、A(200 ，分析型)、For PG、TaurusDB(原 GaussDB For MySQL) ，V2.0（原for openGauss）、GeminiDB redis(原 GaussDB for redis)等多个产品线。每个产品线针对不同的场景，技术栈也不一样。
- TDSQL：包含For MySQL和For PG(TBase)。一个是针对MySQL生态的，一个是针对PG生态的。
- PolarDB：包含X(For MySQL)、PG、O等产品线。同样是多产品线布局，覆盖不同的市场需求。
- GBase：包含 8t(基于informix)、 8a (MySQL)、8s(v8.8基于informix,v8.8.5基于openGauss) 、8c(基于openGauss)
品牌认知误区
用户在选型时，一定要注意区分同一品牌下的不同产品线。它们可能基于不同的技术栈，具有不同的特性和适用场景。比如GaussDB for MySQL和GaussDB for openGauss，虽然都叫GaussDB，但完全是两个不同的产品。
九、AI与数据库的融合
主要进展
- OceanBase：推出了SeekDB，AI原生混合搜索数据库，可嵌入式使用，支持AI应用的向量存储和查询，且内置AI函数能直接调用大模型，甚至还支持对数据来进行版本分支管理。
- GaussDB/openGauss：引入了向量数据库能力，支持AI应用的向量存储和查询。这是目前AI与数据库融合的一个重要方向。
- VastBase/VexDB：在openGauss的引入的向量能力上进一步加强.
- openGauss：推出了嵌入式数据库IntarkDB，个人感觉错失了AI发展机遇，本来可以和seekDB掰掰手腕的。
- Milvus：大多数不做AI开发的人可能不知道还有这么一个数据库，Milvus是一款由中国公司zilliz主导开发的开源向量数据库，在国际上已具有一定影响力。
未来趋势
AI4DB是用AI来优化数据库的性能和运维，DB4AI是用数据库来支持AI应用的训练和推理，这都是过去的概念。新的AI时代来临，LLM技术正在重塑数据库的定位以及使用方式。国产数据库需要加快AI融合步伐，才能在未来的竞争中立于不败之地。
十、其他国产数据库
其他安可数据库
- 瀚高数据库：对PostgreSQL社区贡献最大，算是PG生态的坚定支持者。但商业版HighGoDB的Oracle兼容性不如开源版IvorySQL。
- 万里数据库：专注于MySQL生态。可能由于MySQL的开源协议限制，该数据库也已经开源了。
- 虚谷数据库：自研产品，市场认知度较低。该厂商曾于2020年推出了基于openGauss的有蓉数据库，但后续似乎放弃了openGauss路线，转而回归了自研路线。
- He3DB：中国移动基于PG的云原生数据库，主要服务于中国移动内部的业务。算是内部孵化的产品。
- 优炫数据库：基于PG改造，存在较多负面新闻，但官方公众号一直有新单喜讯。
- 海盒数据库：基于PG的MPP数据库，主要做数据分析场景。
至于其他没有安可认证的数据库，我就不提了。
十一、维保支持：国产数据库的隐形成本
维保支持的现状与挑战
随着国产数据库市场的快速扩张，维保支持能力正成为制约行业发展的关键瓶颈。很多厂商只注重销售，不注重服务，导致客户满意度很低。
- 原厂支持能力不足
- 国产数据库厂商普遍面临客户增长速度远超支持团队扩张速度的问题。销售团队招了很多，支持团队却跟不上。
- 当客户数量达到一定规模后，原厂支持响应速度和质量往往会明显下降。客户打电话过来，半天找不到人，找到了人也解决不了问题。
- 核心技术掌握在少数研发人员手中，一线支持团队缺乏足够的技术授权和问题定位能力。遇到复杂问题，只能把研发人员拉过来，而研发人员又很忙，导致支持流程冗长。
- 资料缺失与依赖原厂
- 国产数据库的技术文档和知识库普遍不够完善，很多问题无法通过自助方式解决。用户遇到问题，只能打电话给原厂，不能自己查资料解决。
- 遇到复杂问题时，往往需要原厂研发人员直接介入分析，导致支持流程冗长。一个问题可能需要好几天才能解决，严重影响了客户的业务。
- 缺乏第三方技术支持生态，客户无法选择其他服务商解决问题。一旦原厂支持跟不上，客户就只能干着急。
- 安全管控与远程排查限制
- 大型企业和金融机构普遍有严格的网络安全管控政策，不允许外部人员随便访问内部网络。
- 原厂技术支持人员无法远程连接客户生产环境进行问题排查，只能通过电话、邮件等方式沟通，效率很低。
- 现场支持成本高、响应慢，进一步降低了支持效率。如果客户在外地，原厂需要派人过去，成本很高，而且响应时间也很长。
维保支持对选型的影响
维保支持能力已经成为企业选型时的重要考量因素。越来越多的客户在选型时，不仅会看产品本身，还会看厂商的支持能力。
- 优先选择生态完善的厂商：具有完善知识库和第三方支持生态的厂商更受青睐。因为这样即使原厂支持跟不上，客户还可以找第三方服务商解决问题。
- 重视服务水平协议(SLA)：客户越来越关注厂商提供的SLA条款和故障响应时效。比如要求厂商在4小时内响应，24小时内解决问题。
- 自主可控的技术能力：具备自主排查和解决问题能力的企业，更倾向于选择开源数据库。因为开源数据库的代码是开放的，企业可以自己排查问题，不需要依赖原厂支持。
未来发展趋势
随着国产数据库市场的成熟，维保支持能力将成为厂商核心竞争力之一。未来，国产数据库厂商需要在以下几个方面加强：
- 加大支持体系建设：包括完善知识库、培训一线支持人员、建立分级响应机制。让一线支持人员能够解决大部分问题，只有复杂问题才需要研发人员介入。
- 第三方支持服务兴起：专业的数据库服务公司将提供独立于原厂的技术支持服务。这样客户就有了更多的选择，不再依赖原厂支持。
- AI辅助支持成为主流：通过AI技术实现智能问题诊断和自动故障修复。比如用AI分析日志，自动定位问题；用AI生成解决方案，自动修复故障。
十二、总结与建议
选型方向
- 商业可持续性：优先选择阿里云、腾讯云、华为云等云厂商的数据库服务。这些厂商有足够的资金和技术实力，能够保证产品的持续迭代和支持。出了事也有钱赔。
- 政策合规性：选择达梦或金仓等央企背景厂商。这些厂商在政企市场有天然的优势，能够满足政策合规要求。
- 国际开源生态：MySQL生态选TiDB/OceanBase，PG生态选Polardb-PG/IvorySQL。这些厂商在开源生态上做得比较好，有完善的社区支持。
- 潜力投资：崖山数据库是具有发展潜力的新兴厂商。虽然入场晚，但架构很好，值得关注。
- 开源免费：openGauss是兼顾兼容性和国产含量的选择。如果预算有限，又需要国产数据库，openGauss是一个不错的选择。
注意事项
- 国产数据库仍存在较多BUG，需要做好测试和版本管理。在上线之前，一定要进行充分的测试，确保产品能够满足业务需求。
- 自动化回归测试至关重要，以应对频繁的版本升级。国产数据库的版本迭代速度很快，需要用自动化测试来保证每次升级都不会引入新的问题。
- 国产数据库版本升级频率远高于Oracle，需要建立相应的运维机制。国产数据库的升级频率可能是Oracle的好几倍，企业需要建立一套完善的升级流程，确保升级过程的平稳。
- 本文作者参与DB2替换的项目较少，因此部分分析不适用于DB2的替换。由于目前国产数据库对DB2兼容性的普遍不佳，建议用户尽早把使用DB2的应用系统进行现代化改造以摆脱对特定数据库的依赖。
免责声明：本文仅代表个人观点，与任何公司无关。文中的分析和建议仅供参考，不构成任何投资或选型建议。
