引言：问题已经不是"有没有"

中国数据库产业到了一个拐点。

产品有了，公司有了，客户有了，路线也有了。问题从"有没有国产数据库"变成了——在 Oracle、DB2、MySQL、PostgreSQL 定义了二十多年企业数据底座之后，谁能接住旧系统的重量，谁才能进下一轮。

去 IOE、信创、分布式、云原生、开源——每一轮叙事都把行业往前推，也制造相似的乐观。机会当然来了，问题是：机会已经不再稀缺。

中国数据库的淘汰赛，开始于机会不再稀缺之后。

一、为什么数据库是中国软件最难啃的骨头

数据库在企业里的特殊位置

数据库不像办公软件那么容易被看见，也不像芯片那样天然带着物理门槛。但它偏偏卡在最关键的位置：上面是应用系统，下面是服务器、存储和网络。

一旦数据库变成核心系统底座，组织对它的要求就陡然升级：

数据库不像一件单独的软件，更像一个把技术和组织绑在一起的系统。

两个起点：工程积累与国家投入

中国本土数据库厂商的时间线：

这些公司最早走的不是互联网爆发式路线，而是先在政企和关键行业外圈扎根，再逐步往核心系统渗透。这条路径不性感，但构成了中国数据库最初的工业化底色。

"存在" → "替代" → "创新"——这是国产数据库的三步走，每一步都比上一步难一个量级。

为什么领先优势很难靠一次押注反超

TPC-C 历史成绩里，Oracle Database 和 IBM DB2 在 2000-2010 年代长期占据高位。这不是简单的"国外更先进"，而是数据库行业领先优势的本质：

产品内核
  → 工具链
    → 伙伴生态
      → 开发者习惯
        → 客户验证
          → 运维经验
            → 惯性（几乎无法撬动）

企业真正沉淀下来的资产不只是"买了哪个数据库许可证"，而是 SQL、存储过程、ORM、运维脚本、监控体系和人的经验。谁接手数据库，谁就得接手这些东西。

数据库行业从来不是谁把产品做出来谁就赢。谁接得住旧系统的重量，谁才有资格进下一轮。

二、两波历史：去 IOE 和信创

去 IOE：高速公路换轮子

去 IOE 最重要的不是"把 IBM、Oracle、EMC 换掉"，而是互联网公司第一次用自己的业务压力，逼着数据库从集中式扩容走向分布式扩展。

阿里那段公开复盘的核心场景：

淘宝早期选择 Oracle → 最成熟的企业级方案
    ↓
业务规模爆发 → 集中式上限暴露 + 黑盒问题 + 成本飙升 + 响应效率下降
    ↓
被迫转向 DRDS/TDDL + MySQL 体系化改造
    ↓
"高速公路换轮子"——不是路线错了，是规模变了

这段历史留下了两个长期后果：

1. 数据库替换从来不是数据库团队自己的事——它一定牵动应用架构、研发流程、运维体系和管理模式
2. 后来厂商反复强调的"兼容性""迁移工具链""运维平台"——不是天然的产品天赋，而是在补这段历史欠下的工程账

信创：从技术社区走向制度化

信创和开源的意义：把竞争方式从"单一厂商交付"改成"厂商 + 社区 + 发行版 + 服务商"的组合战。过去数据库像封闭企业软件，之后逐渐变成平台化底座的一部分。

三股力量叠加

中国数据库过去二十年的机会，不只是政策给的。更准确地说是三股力量叠在一起：

长期的基础软件投入（核高基/政企市场）
    +
互联网公司被高并发逼出来的工程方法（去 IOE/分布式）
    +
信创和开源把能力制度化、生态化
    =
从"有没有机会进入客户名单" → "进入名单后谁能留下来"

过去的窗口让更多公司进场，今天更高的门槛开始逼行业分出胜负。

三、创新的真实含义：不是发明新物种，是拆解旧能力

几股力量的路线分野

中国数据库真正的创新

不是发明了一个全新数据库物种，而是把"过去只能由国外成熟厂商承担的能力"，逐步拆成了几种本土可验证的工程路线。

最明显的一条线：分布式事务系统的工程化。TPC-C 公开榜单（2026 年 3 月）：

多数企业不会只看 TPC-C 选型，但这个榜单至少说明：中国厂商已经不只是在做"能兼容 Oracle 的替代品"，也在做"能把分布式事务系统跑到极限规模"的产品。

不同的出身，同一个问题

各家的路不一样，但都在回答同一个问题：企业到底要一套什么样的数据库，才愿意把关键系统交给它？

• OceanBase：先在阿里体系内被极限场景逼出来，再向外生长
• TiDB：先把 HTAP 写进产品定义，再通过社区放大影响
• PolarDB：云原生数据库产品化能力，背后是阿里云基础设施
• TDSQL：金融级可用性 + 强一致 + 分布式事务 + 兼容 SQL 绑在一起卖
• GaussDB/openGauss：一头连华为企业客户体系，一头连社区和伙伴生态

下一轮：HTAP、多模、AI 原生

《数据库发展研究报告（2024 年）》列出的方向：向量数据库、多模数据库、AI 赋能运维、大语言模型降低操作门槛。

这说明下一轮竞争不只是在事务处理上做文章，而是在争夺一个更大的位置：谁能同时处理事务、分析、检索和模型协同。

但这仍然更像一个正在成形的方向，而非已经兑现的产业结果。能发布一条新路线，和能让客户把关键系统交给这条路线，中间永远隔着一大段工程距离。

今天行业最真实的分野不是"谁会不会讲创新"，而是三件事谁能同时做到：一边补旧账、一边建新能力、一边让客户真的敢用。

四、一地鸡毛：真正的代价不在发布会，在迁移和运维

第一层鸡毛：兼容

各家的兼容策略：

兼容的商业含义很直白：中国数据库行业过去很多年的商业入口，本质上就是兼容 Oracle/MySQL/PostgreSQL。

说"兼容 Oracle"其实是在对客户说：我不要求你把过去十几年的系统全部推倒重来。

但兼容的另一面是——很难真正干净：

越想快速替代 → 越要做兼容
    → 越做深度兼容 → 越容易被旧生态牵着走
        → 今天通过兼容签下单子
            → 明天在边缘差异里为稳定性付出成本

兼容性不是单纯的产品卖点，它本身就是包袱。

第二层鸡毛：分布式

一个常见误解：分布式等于更先进，所以问题更少。现实恰好相反。

分布式把集中式时代隐藏的问题重新暴露出来：

分布式带来的不是"鸡毛更少"，而是"鸡毛换了形态"。

第三层鸡毛：生态

MySQL 使用双重许可模式（GPL + 商业许可）。一旦数据库被当成平台软件去集成、分发、交付，合规和授权就变成真实约束。

数据库生态问题的本质：

没有生态 → 只能卖产品（有限场景生存）
有了生态 → 才可能变成平台（网络效应）
    但生态本身也要成本、时间、市场规模

最现实的一层：核心系统门槛

部分银行公告仍提到 Oracle 在核心生产系统中的存在。这说明数据库国产替代不是"新系统天然用国产、旧系统慢慢退休"那么轻松，而是终究要推进到最难的一步：存量核心系统怎么迁。

到了这里，所有事情都会变得更贵、更慢、更不能犯错：

• 任何一次小概率故障 → 从技术问题变成业务事故
• 任何一次"为了替代而替代"的迁移 → 测试、回滚、双轨运行和人员能力建设没跟上，就会反噬

鸡毛不是失败的证据

"一地鸡毛"恰恰说明这个行业终于进入了最真实的阶段：客户不再只看名字、口号和路线，而是把问题压缩成最朴素的几件事：

到了这一步，数据库公司卖的不只是内核，而是整套工程资产。淘汰赛从这一刻才真正开始。

五、淘汰赛的三种决胜能力

数据库不是轻交付、低迁移成本的市场，客户不会频繁更换底座。玩家足够多，最终一定会分化：一部分被并购，一部分被边缘化，一部分转向细分场景，少数留在平台底座位置。

能力一：硬引擎能力

不是抽象的"技术领先"，而是能不能在极限场景下证明自己。

TPC-C 不是全部，但至少让 PolarDB、TDSQL、OceanBase 有了公开、粗暴、谁都看得懂的证明：国内厂商已经可以把分布式事务数据库做到全球第一梯队。

没有这层能力，数据库公司很难进入更苛刻的核心系统对话。

能力二：迁移工程化能力

达梦的兼容模式、人大金仓的 Oracle 接口支持、TDSQL 的 Oracle 模式，本质上都在做同一件事：把"替代"从一句市场口号，变成一套工具、参数、流程和知识库。

客户最后要买的不是"国产数据库"概念，而是一条尽可能少返工、少停机、少惊吓的迁移路径。谁能把 Oracle/MySQL/PostgreSQL 留下来的资产接得更平稳，谁就更容易吃到存量市场。

能力三：生态组织能力

openGauss 和 OceanBase 的开源化说明一个现实：数据库不可能只靠单一厂商扛到最后。

伙伴、社区、发行版、服务商、开发者——这些东西不会直接体现在内核代码里，却决定数据库到底是一个产品还是一个平台。

两条路线终将在同一张桌子碰面

未来行业分化不会简单落在"传统国产厂商"和"互联网/云厂商"谁替代谁上：

大家最终会在同一张桌子上碰面。真正的竞争不是谁消灭谁，而是谁能先补齐自己最短的那块板。

六、总结：淘汰赛的本质

"自主、创新与一地鸡毛"不是三段式的顺序关系，而是同一件事的三个面：

兼容的长尾、迁移的双轨、分布式的故障边界、生态和人才的缺口、核心系统对稳定性的苛刻要求——这些东西不会因为口号更响而消失，只会因为工程方法更扎实而慢慢下降。

中国数据库过去二十年的主线，归根结底不是"有没有做出国产数据库"，而是谁能把替代留下来的鸡毛、创新带来的副作用，一点点做成自己的工程资产。

到了今天，这个行业真正可贵的变化也许不是更会讲故事，而是终于没法只靠故事往前走了。

它开始回到企业软件最朴素的逻辑：

谁能长期稳定地跑，谁才配留下来。