OceanBase vs TiDB：金融级分布式数据库的技术路线之争#
📌 核心观点
OceanBase 与 TiDB 的竞争，不应该简单理解为：
“谁性能更高？”
更准确的问题是：
“两套完全不同的分布式数据库技术路线，谁更适合哪一种金融业务？”
OceanBase 更强调：
金融级 OLTP + 强一致 + Oracle/MySQL 双兼容 + 一体化分布式架构
TiDB 更强调：
MySQL 生态 + 计算存储分离 + 弹性扩展 + HTAP + 云原生
二者都解决了传统单机数据库难以解决的问题：
- 水平扩展
- 分布式事务
- 高可用
- 多副本
- 容灾
- 海量数据
但解决问题的方式并不一样。
如果把传统数据库比作：
一台性能极高的大型机器那么：
OceanBase ≈ 把这台机器拆成一个金融级分布式系统而：
TiDB ≈ 把 MySQL 业务拆成云原生的计算、存储、分析基础设施这就是两条路线最根本的区别。
一、为什么 OceanBase 与 TiDB 经常被放在一起比较？#
因为它们具有高度重叠的能力边界：
- 原生分布式
- SQL 数据库
- MySQL 生态兼容
- 水平扩展
- 多副本
- 分布式事务
- 金融场景落地
- 云原生部署
- HTAP 能力
但是：
“都能做”不代表“都以同一种方式做”。
真正的差异隐藏在：
架构
↓
一致性协议
↓
事务模型
↓
存储引擎
↓
兼容策略
↓
运维模式
↓
金融场景因此，OceanBase vs TiDB，实际上是：
金融原生分布式数据库 vs 云原生分布式 SQL
的一场路线之争。
二、出身决定路线：两个数据库的技术基因#
这是理解两者差异最好的入口。
2.1 OceanBase：从“去 IOE”中诞生#
OceanBase 的技术背景，与蚂蚁的“去 IOE”历史密切相关。
典型发展脉络可以概括为：
传统 IOE 架构
↓
支付宝业务规模快速增长
↓
集中式数据库压力持续增加
↓
2009 左右开始分布式数据库探索
↓
OceanBase
↓
金融级分布式数据库文中材料给出的代表性节点包括：
2009
OceanBase 立项
↓
2013
支付宝最后一台小型机下线
↓
2017
双十一支付峰值达到数十万笔/秒
↓
2020
TPC-C 创纪录
↓
持续进入银行、证券、支付等金融场景因此 OceanBase 的底层基因非常鲜明：
先解决金融级高并发 OLTP，再解决通用分布式数据库问题。
2.2 TiDB：从 MySQL 水平扩展中成长#
TiDB 的出发点不同。
它最初解决的是：
单机 MySQL 无法继续水平扩展。
典型问题：
MySQL
↓
数据越来越大
↓
单机扩容越来越贵
↓
分库分表越来越复杂
↓
开发和运维成本暴涨于是 TiDB 的目标变成：
MySQL 生态
↓
Distributed SQL
↓
Horizontal Scaling因此 TiDB 从一开始就更强调：
- MySQL 兼容
- 云原生
- 计算存储分离
- 水平扩展
- HTAP
所以可以简单概括：
OceanBase 是金融业务极限场景逼出来的；TiDB 是大规模 MySQL 弹性扩展逼出来的。
三、两个数据库的“出生基因”对照#
| 维度 | OceanBase | TiDB |
|---|---|---|
| 起源 | 蚂蚁分布式金融基础设施 | 大规模 MySQL 扩展 |
| 首要问题 | 金融级 OLTP | 水平扩展 |
| 设计倾向 | 强一致、事务、高并发 | 弹性、分离、HTAP |
| 兼容策略 | Oracle + MySQL | MySQL 优先 |
| 架构起点 | 计算存储一体化 | 计算存储分离 |
| 典型用户 | 金融核心系统 | MySQL 大型业务 |
这也意味着：
两者的技术路线差异，是从产品诞生的第一天就存在的。
四、OceanBase：单机分布式一体化#
OceanBase 采用 Shared-Nothing 思路，但一个核心特点非常明显：
计算和存储在同一类 OBServer 节点中完成。
典型架构：
Application
↓
OBProxy
↓
+------------+------------+
| | |
OBServer OBServer OBServer
Zone 1 Zone 2 Zone 3
| | |
+------------+------------+
↓
Paxos Replication每个节点通常同时承担：
- SQL 计算
- 数据存储
- 事务处理
- 副本维护
五、OceanBase 一体化架构的好处#
5.1 组件少#
典型部署不需要像计算存储分离架构那样部署大量独立角色。
因此：
部署
→
配置
→
监控
→
故障排查相对集中。
5.2 数据本地性更强#
SQL 计算与数据存储在相同节点体系内。
可以减少：
Compute
↓
Network
↓
Storage之间的跨层网络交互。
对于 OLTP 场景：
本地性通常非常重要。
5.3 事务处理路径更短#
在很多典型事务场景中：
SQL
↓
Transaction
↓
Storage都在同一个分布式数据库体系内部完成。
因此 OceanBase 更偏：
数据库本身就是一个完整的金融分布式事务平台。
六、OceanBase 的 Multi-Paxos 路线#
OceanBase 的一致性路线是：
Multi-Paxos
一个典型分区可以拥有多个副本：
Partition
+-----------+-----------+-----------+
| Replica A | Replica B | Replica C |
+-----------+-----------+-----------+
\ | /
Majority当多数副本完成持久化确认后：
Commit因此：
一致性是 OceanBase 架构的核心，而不是附加功能。
七、为什么 Paxos 对金融系统有吸引力？#
金融核心业务需要：
多个节点
+
多机房
+
多副本
+
一致性如果：
Node A出故障：
Node B / C仍然能够继续完成事务状态确认。
这类架构特别适合：
- 银行核心
- 支付
- 清算
- 证券核心交易
- 高可靠账务
八、OceanBase 的多租户能力#
OceanBase 另一个非常重要的设计是：
原生多租户。
可以抽象为：
OceanBase Cluster
├── Tenant A
│ ├── CPU
│ ├── Memory
│ └── Storage
│
├── Tenant B
│ ├── CPU
│ ├── Memory
│ └── Storage
│
└── Tenant C
├── CPU
├── Memory
└── Storage这对于金融机构非常有意义。
因为大型金融机构通常不是：
一个系统
+
一个数据库而是：
核心交易
+
账务
+
清算
+
风控
+
渠道
+
管理大量业务数据库需要统一治理。
九、OceanBase 的 Oracle + MySQL 双模式#
这是 OB 非常重要的竞争优势之一。
它不仅支持：
MySQL Mode还支持：
Oracle Mode意味着：
传统 Oracle
↓
OceanBase可以在更大程度上降低迁移成本。
尤其是涉及：
- PL/SQL
- 存储过程
- Oracle 数据类型
- Oracle 开发习惯
的核心金融系统。
十、TiDB：计算存储分离路线#
TiDB 的架构完全不同。
典型体系：
Application
↓
TiDB Server
Stateless SQL Layer
|
+------------+------------+
| |
v v
TiKV TiFlash
Row Storage Column Storage
| |
+------------+------------+
|
v
PD
Metadata / TSO这里最重要的概念：
SQL、行存、列存、元数据管理彼此解耦。
十一、为什么 TiDB 要做计算存储分离？#
因为它希望：
计算能力和存储能力可以独立扩展。
例如：
如果 SQL 计算压力突然增加：
TiDB Server
3
↓
6
↓
12不一定需要同时扩展存储。
如果数据量快速增长：
TiKV
3
↓
6
↓
12也可以独立扩容。
这就是：
云原生弹性。
十二、TiDB 的三层架构#
TiDB Server#
负责：
- SQL Parser
- SQL Optimizer
- Query Execution
- Connection
特点：
无状态。
TiKV#
负责：
- 行存
- 数据持久化
- Raft
- 分布式事务
TiFlash#
负责：
- 列式存储
- OLAP
- 实时分析
PD#
负责：
- 元数据
- Region 调度
- 全局时间戳
所以：
TiDB
=
SQL Compute
TiKV
=
Distributed OLTP Storage
TiFlash
=
OLAP Engine
PD
=
Control Plane十三、TiDB 的 Multi-Raft#
TiDB 的一致性协议主要建立在：
Raft
之上。
每一个 Region 通常有多个副本：
Region
+---------+---------+---------+
| Leader | Follower| Follower|
+---------+---------+---------+Leader：
Read / WriteFollower：
Replication多数派：
Commit这让 TiDB 同样能够提供：
分布式强一致事务能力。
十四、Paxos vs Raft：到底谁更强？#
这是技术讨论中最容易陷入误区的地方。
不能简单说：
Paxos > Raft或者：
Raft > Paxos因为：
工程实现远比协议名字复杂。
真正决定系统表现的是：
Consensus Protocol
+
Storage Engine
+
Transaction Layer
+
Network
+
Scheduler
+
Failure Recovery因此：
Paxos 和 Raft 本身不是产品性能的充分条件。
十五、OceanBase：分布式事务模型#
OceanBase 的典型设计强调：
Global Timestamp
+
Distributed 2PC典型路径：
Client
↓
Transaction Coordinator
↓
Partition A
Partition B
Partition C
↓
Prepare
↓
Commit对于单分区事务，还可以通过：
1PC减少不必要的协调开销。
十六、TiDB：Percolator + TSO#
TiDB 的事务体系源于 Percolator 思路。
基本概念：
Start Timestamp
↓
Read / Write
↓
Commit Timestamp全局时间戳由：
PD提供。
TiDB 支持：
- 悲观事务
- 乐观事务
- RC
- RR
因此：
TiDB 更强调通用分布式事务能力和 MySQL 开发习惯的兼容。
十七、事务模型对比#
| 维度 | OceanBase | TiDB |
|---|---|---|
| 核心模型 | 2PC + 全局时间戳 | Percolator + TSO |
| 事务模式 | 强调金融 OLTP | 通用分布式事务 |
| 事务策略 | 悲观场景优势明显 | 乐观/悲观双模式 |
| 单分区优化 | 1PC 等优化 | 本地事务优化 |
| 典型优势 | 核心账务 | 大规模 MySQL 业务 |
十八、存储引擎：两个完全不同的答案#
这是第二个非常关键的差异。
OceanBase：自研 LSM-Tree#
可以简单理解：
MemTable
↓
SSTable
↓
Compaction典型特点：
- 增量数据进入内存
- 后台进行合并
- 压缩率较高
- 适合高写入场景
同时 OceanBase 还进一步发展：
行列融合。
十九、TiDB：RocksDB + TiFlash#
TiKV 使用：
RocksDB作为底层存储引擎。
典型写路径：
MemTable
↓
WAL
↓
Raft
↓
Persist而 TiFlash 则采用独立的列存体系：
TiKV
↓
Multi-Raft Learner
↓
TiFlash因此 TiDB 本质上是：
行存 + 列存双引擎。
二十、HTAP：OceanBase 与 TiDB 的两种路线#
HTAP：
Hybrid Transaction / Analytical Processing
目标：
OLTP
+
OLAP同时运行。
OceanBase#
更强调：
行列融合
+
统一数据体系即：
Transactional Data
↓
Analytical Processing特点：
- 减少数据复制
- 存储成本相对较低
- 更接近一体化数据库
TiDB#
则更明确地采用：
TiKV
+
TiFlash双引擎。
优势：
OLTP 与 OLAP 可以进行更彻底的资源隔离。
也就是说：
OLTP
↓
TiKV
OLAP
↓
TiFlash一个负责交易，一个负责分析。
二十一、HTAP 路线的本质差异#
| 维度 | OceanBase | TiDB |
|---|---|---|
| 行存 | 原生 | TiKV |
| 列存 | 内核融合/列存能力 | TiFlash |
| 复制模式 | 更偏统一数据体系 | 独立列存副本 |
| 资源隔离 | 一体化 | 更彻底的物理分离 |
| 存储成本 | 更强调降低重复存储 | 更多存储换隔离 |
| 架构风格 | Integrated HTAP | Decoupled HTAP |
所以：
OceanBase 更像“一份数据，多种计算方式”。
TiDB 更像“一套数据，两个专业引擎”。
二十二、最关键的兼容性之争：Oracle vs MySQL#
对于金融行业而言：
数据库迁移最大的成本经常不是数据，而是应用。
OceanBase#
支持：
MySQL Mode
+
Oracle Mode因此：
Oracle
↓
OceanBase可以大幅降低迁移难度。
尤其是：
- PL/SQL
- 存储过程
- Oracle SQL
- Oracle 数据类型
TiDB#
核心战略：
MySQL 生态优先。
典型迁移：
MySQL
↓
TiDB相对自然。
因此可以形成：
“Oracle 迁移优先考虑 OB，MySQL 扩展优先考虑 TiDB”
这样的经验规则。
二十三、兼容性对比#
| 维度 | OceanBase | TiDB |
|---|---|---|
| MySQL | 支持 | 核心优势 |
| Oracle | 原生模式支持 | 非目标 |
| PL/SQL | 支持 Oracle 模式 | 不以此为目标 |
| MySQL 生态 | 强 | 极强 |
| Oracle 迁移 | 优势明显 | 需要更多改造 |
| MySQL 迁移 | 较平滑 | 非常自然 |
因此：
数据库选型第一问，往往不是“性能多少”，而是“我要从什么迁过来”。
二十四、金融场景：OceanBase 的典型优势#
从本文提供的案例口径看，OceanBase 的金融落地更多集中在：
核心账务
+
支付
+
银行核心
+
证券核心
+
Oracle 替换典型案例包括：
- 支付宝核心账务
- 银行信用卡核心
- 证券估值系统
- 银行核心系统迁移
这些场景共同特点是：
OLTP 极重，而且一致性要求极高。
二十五、OceanBase：支付宝类场景#
典型逻辑：
Payment
↓
Account
↓
Ledger
↓
Settlement数据库必须处理：
- 极高并发
- 强一致
- 高可用
- 多副本
- 容灾
- 大规模数据
因此：
OceanBase 的产品哲学非常接近“金融核心数据库”。
二十六、OceanBase：证券估值类场景#
证券系统一般具有：
账户
+
持仓
+
估值
+
清算
+
风险这种场景需要：
- 高吞吐
- 多租户
- 数据一致性
- 实时计算
也是 OceanBase 强项。
二十七、TiDB：金融场景的另一条路线#
TiDB 在金融领域的案例更多体现：
Oracle / MySQL 迁移
+
水平扩展
+
HTAP
+
云原生典型场景：
- 银行核心系统
- 支付系统
- 账务系统
- 金融渠道
- 数据分析
二十八、杭州银行：TiDB 路线的代表意义#
文中提供的案例强调：
Oracle
↓
TiDB以及：
两地三中心
+
多副本
+
RPO = 0
+
快速恢复这说明：
TiDB 并不等于“互联网数据库”。
随着金融实践深入，它同样可以进入：
金融级 OLTP
领域。
二十九、微众银行：TiDB 的规模化基因#
文中案例还强调：
- 集群数量增长
- PB 级容量
- 多业务覆盖
- 大规模节点
- 高 QPS
- 自研管理平台
这体现出 TiDB 的核心价值：
不是单纯替代 MySQL，而是把 MySQL 业务的规模边界往外推。
三十、两种金融数据库路线的真正差异#
可以简单抽象成：
OceanBase
金融核心
↓
强一致
↓
极致 OLTP
↓
一体化而：
TiDB
MySQL 业务
↓
水平扩展
↓
HTAP
↓
云原生因此：
OB 更像“金融核心数据库”，TiDB 更像“云原生金融分布式 SQL 平台”。
这不是价值判断。
是路线判断。
三十一、五大维度全面对比#
31.1 架构#
| OceanBase | TiDB | |
|---|---|---|
| 计算存储 | 一体化 | 分离 |
| 扩展粒度 | 节点级 | 组件级 |
| 组件复杂度 | 较低 | 较高 |
| 弹性 | 强 | 很强 |
| 云原生 | 支持 | 原生优势 |
31.2 一致性#
| OceanBase | TiDB | |
|---|---|---|
| Consensus | Paxos | Raft |
| 副本 | 多副本 | 多副本 |
| 强一致 | 支持 | 支持 |
| 金融容灾 | 强 | 强 |
| 跨地域 | 原生能力较强 | 依赖部署与额外机制 |
31.3 事务#
| OceanBase | TiDB | |
|---|---|---|
| 事务模型 | 2PC | Percolator |
| Timestamp | GTS | TSO |
| 事务模式 | 强调金融 OLTP | 乐观 + 悲观 |
| 适合 | 核心账务 | 通用分布式业务 |
31.4 存储#
| OceanBase | TiDB | |
|---|---|---|
| 行存 | LSM | RocksDB |
| 列存 | 内核融合 | TiFlash |
| HTAP | 行列融合 | 双引擎 |
| 扩展 | 一体化 | 分离式 |
31.5 生态#
| OceanBase | TiDB | |
|---|---|---|
| Oracle | 强 | 弱 |
| MySQL | 强 | 极强 |
| Kubernetes | 支持 | 原生 |
| 社区 | 快速发展 | 开源生态成熟 |
| 金融落地 | 强 | 强 |
三十二、性能到底谁更强？#
这是最容易被营销材料带偏的问题。
不能简单比较：
OB = X TPS
TiDB = Y TPS因为：
不同测试环境、不同 SQL、不同硬件、不同数据规模，结果完全不同。
尤其需要区分：
- Benchmark
- 单表
- 单分区
- 跨分区事务
- OLTP
- OLAP
- HTAP
- 混合压力
所以：
性能指标必须绑定 workload。
三十三、真正应该测什么？#
金融机构做数据库 POC，至少应该测试：
OLTP#
TPS
QPS
P99 Latency
P999 LatencyTransaction#
Single Partition
Cross Partition
High ContentionFailover#
Node Failure
AZ Failure
Network Partition
Disk FailureRecovery#
RPO
RTO
Replay Time
Data Repair TimeHTAP#
OLTP + OLAP
Concurrent LoadMigration#
SQL Compatibility
Stored Procedure
Data Type
Character Set
Application Rewrite真正重要的不是：
“官网最高 TPS 是多少？”
而是：
“在我的真实 workload 下，谁更稳定？”
三十四、容灾能力：不要只看 RPO/RTO#
很多数据库宣传：
RPO = 0
RTO < 30s但金融机构真正应该问：
城市级故障怎么办？
机房级故障怎么办？
网络分区怎么办？
脑裂怎么办？
数据回滚怎么办？
切换后应用如何恢复？所以：
容灾不是数据库单点能力，而是数据库 + 网络 + 调度 + 应用 + 运营体系的整体能力。
三十五、OceanBase 更适合什么？#
结合本文材料，可以形成一个较清晰的选型画像。
优先考虑 OceanBase#
Oracle Core
↓
金融核心账务
↓
强一致 OLTP
↓
大型多租户
↓
复杂容灾尤其适合：
- Oracle 核心系统替换
- 银行核心
- 支付核心
- 证券核心交易/估值
- 大规模 OLTP
- 强一致金融数据库
三十六、TiDB 更适合什么？#
优先考虑 TiDB#
MySQL
↓
水平扩展
↓
HTAP
↓
云原生尤其适合：
- MySQL 单机扩展
- 大型互联网金融业务
- HTAP
- 数据规模快速增长
- Kubernetes 原生部署
- 需要较强 MySQL 生态兼容
三十七、不要误解成“二选一”#
大型金融机构很少真的需要：
全行统一一个数据库更现实的是：
Financial Institution
+-----------+-----------+
| | |
v v v
Core Channels Risk
| | |
v v v
OceanBase TiDB Other DB
| | |
+-----------+-----------+
|
v
Data Platform也就是说：
数据库最终可能走多引擎协同。
三十八、“一行多库”可能成为常态#
例如：
核心账务
→ OceanBase
互联网渠道
→ TiDB
分析平台
→ TiDB / Lakehouse
遗留系统
→ Oracle
特定场景
→ PostgreSQL / MySQL这种架构不一定意味着混乱。
如果：
标准统一
+
数据治理
+
统一监控
+
统一备份
+
统一安全那么多数据库反而能实现：
按业务特性选择最合适的数据库。
三十九、未来路线：两边开始互相学习#
OceanBase 正在增强：
- Kubernetes
- 云化
- HTAP
- 向量能力
- AI 数据处理
TiDB 也正在增强：
- 金融事务
- 悲观事务
- 更强一致性
- 金融容灾
- AI 数据能力
于是：
OceanBase
金融原生
↓
开始吸收云原生能力而：
TiDB
云原生
↓
开始强化金融能力四十、最终可能出现“第三条路线”#
未来数据库可能不再是：
OLTP Database
或者
OLAP Database而是：
Financial Distributed Database
+
HTAP
+
Vector
+
AI
+
Cloud Native即：
AI-Native Distributed Database
典型架构可能是：
Application
|
v
Distributed SQL
|
+-------------+-------------+
| | |
v v v
OLTP HTAP Vector
| | |
+-------------+-------------+
|
v
Distributed Storage
|
v
Consensus
|
v
Cloud Native四十一、AI 对数据库的真正影响#
AI 不仅仅是：
“给数据库加一个向量索引。”
更大的变化是：
1. 查询智能化#
Natural Language
↓
SQL
↓
Query Optimization2. 运维智能化#
Metrics
↓
AI Diagnosis
↓
Root Cause
↓
Auto Remediation3. 数据智能化#
Structured Data
+
Vector
+
Knowledge Graph最终形成：
数据库从“数据存储系统”变成“智能数据基础设施”。
四十二、路线之争最终不是“谁赢”#
OceanBase 与 TiDB 的竞争真正推动的是：
传统 Oracle
↓
分布式数据库
↓
金融级分布式数据库
↓
云原生数据库
↓
HTAP
↓
AI Database两家产品实际上都在推动这个过程。
因此：
路线竞争的最大赢家，最终可能是整个金融 IT 行业。
四十三、OceanBase vs TiDB 终极选型表#
| 维度 | OceanBase | TiDB |
|---|---|---|
| 架构 | 一体化 | 计算存储分离 |
| Consensus | Multi-Paxos | Multi-Raft |
| 事务 | 2PC + GTS | Percolator + TSO |
| 存储 | 自研 LSM | RocksDB + TiFlash |
| MySQL | 支持 | 核心优势 |
| Oracle | 强项 | 弱 |
| HTAP | 行列融合 | TiKV + TiFlash |
| 多租户 | 原生 | 持续增强 |
| 云原生 | 支持 | 强项 |
| 金融核心 | 强项 | 可支持 |
| MySQL 扩展 | 强 | 强项 |
| Oracle 替换 | 非常适合 | 改造成本更高 |
| HTAP | 强 | 强项 |
| K8s | 支持 | 原生优势 |
四十四、最终结论：不是谁更强，而是谁更适合#
回到开头的问题：
OceanBase 和 TiDB 到底谁更强？
如果只问这一句话：
没有意义。
正确的问题应该是：
我的源数据库是什么？
我的业务是什么？
我的事务模型是什么？
我的数据规模是多少？
我要 OLTP 还是 HTAP？
我需要 Oracle 兼容吗？
我要不要 Kubernetes？
我的容灾等级是什么？
团队到底擅长什么？然后再选择。
四十五、可以用一句话理解两条路线#
OceanBase#
从金融核心问题出发，把分布式数据库做成一个金融级 OLTP 基础设施。
路线：
金融核心
↓
强一致
↓
高可用
↓
Oracle 兼容
↓
分布式
↓
云原生TiDB#
从 MySQL 扩展问题出发，把关系数据库做成一个云原生分布式 SQL 平台。
路线：
MySQL
↓
水平扩展
↓
分布式 SQL
↓
HTAP
↓
Kubernetes
↓
AI四十六、结语：真正的路线之争，其实是场景之争#
OceanBase 与 TiDB 并不是：
Winner
vs
Loser而是：
Financial-Native
vs
Cloud-Native两条路线的碰撞。
OceanBase 更偏向：
核心账务、支付、证券、Oracle 替换、强一致 OLTP。
TiDB 更偏向：
MySQL 生态、水平扩展、HTAP、云原生和大规模数据业务。
但今天这条边界正在快速变模糊：
OceanBase
↓
Cloud Native
HTAP
Vector
AI
TiDB
↓
Financial Transactions
Financial DR
Financial Core
AI所以未来真正的竞争可能不再是：
OceanBase vs TiDB
而是：
谁能够同时解决金融级一致性、云原生弹性和 AI 数据处理。
也就是：
Strong Consistency
+
Elastic Scaling
+
HTAP
+
Vector
+
AI
+
Cloud Native最终形成：
AI-Native Distributed Financial Database
附：数据库选型决策树#
Start
|
v
Existing Database?
/ \
/ \
Oracle MySQL
| |
v v
Need PL/SQL? Need Horizontal Scale?
/ \ / \
Yes No Yes No
| | | |
v v v v
OceanBase POC TiDB Traditional
| |
+--------+---------+
|
v
Need HTAP?
/ \
Yes No
| |
v v
TiDB / OB Based on OLTP
|
v
Need Extreme
Financial
Consistency?
/ \
Yes No
| |
v v
OceanBase TiDB博主注
数据库选型最危险的错误，不是选错某一个产品，而是用错误的评价体系评价产品。
如果用：
Benchmark TPS去评价一个金融核心数据库，很容易得出错误结论。
如果只看：
MySQL Compatibility又可能忽略事务、容灾、运维和数据迁移成本。
真正成熟的数据库选型应该同时看：
架构、事务、一致性、兼容性、存储、HTAP、容灾、云原生、运维和团队能力。
OceanBase 和 TiDB 的竞争，本质上不是“谁替代谁”，而是：
谁能在自己的优势路线之外，把对方真正擅长的能力也补齐。
当 OceanBase 越来越云原生，TiDB 越来越金融级时，数据库行业正在进入一个新的阶段：
金融数据库不再只是“金融数据库”，云数据库也不再只是“互联网数据库”。
最终的产品形态，很可能是：
金融级一致性 + 云原生弹性 + HTAP + AI + 向量数据
的统一分布式数据基础设施。
这才是 OceanBase 与 TiDB 这场路线之争真正值得关注的地方。