分布式数据库开源项目全景对比

调研时间：2026-06-22 目的：横向对比分布式数据库 / HTAP 赛道的主流开源项目，为犀牛鸟参与做知识储备

6 个项目一览

#	项目	Stars	主语言	核心设计思路	仓库
1	TiDB	~41K	Go	原生分布式 HTAP，MySQL 兼容，TiKV 行存 + TiFlash 列存	`pingcap/tidb`
2	CockroachDB	~32K	Go	云原生分布式 SQL，PostgreSQL 兼容，Spanner 设计	`cockroachdb/cockroach`
3	Vitess	~21K	Go	CNCF 毕业，MySQL 水平分片中间件，YouTube 出品	`vitessio/vitess`
4	Citus	~12.5K	C	PostgreSQL 扩展，分布式查询，Microsoft 收购	`citusdata/citus`
5	YugabyteDB	~10.5K	C/C++	PostgreSQL + Cassandra 双兼容，Spanner 架构	`yugabyte/yugabyte-db`
6	OpenTenBase	~2K	C	腾讯开源，基于 Postgres-XL 的分布式 HTAP	`OpenTenBase/OpenTenBase`

设计思路对比

架构模式（核心差异）

每个项目对”如何把单机数据库变成分布式”这个问题给出了不同答案：

原生分布式模式（TiDB）：从零开始设计分布式架构——SQL 层（tidb-server）负责解析和优化，存储层分成 TiKV（行存，处理 TP 事务）和 TiFlash（列存，处理 AP 分析），通过 Raft 协议保证一致性。类比：一家大公司把”接待前台”和”仓库管理”完全分开——前台只管理解客户需求，仓库只管存取货物，中间靠物流系统（PD 调度器）协调。

Spanner 继承者模式（CockroachDB）：直接复刻 Google Spanner 的设计——全局有序 KV 存储 + 分布式事务 + 自动分片。每个节点既能处理 SQL 又能存储数据，没有单独的存储层。类比：一个连锁超市的每家分店都能独立运营（收银+库存），总部只需要协调价格和库存调拨，任何一家店关门其他店照常运转。

中间件代理模式（Vitess）：不改 MySQL 本身，在外面加一层代理——VTGate 接收 SQL 请求，VTTablet 管理每个 MySQL 实例，拓扑服务（etcd/ZooKeeper）记录分片映射。类比：在已有的多个小仓库前面设一个”调度中心”，客户只跟调度中心打交道，不需要知道货物在哪个仓库。

扩展插件模式（Citus）：作为 PostgreSQL 的 extension 运行，不 fork 不魔改，共享 PostgreSQL 的升级和生态。协调节点把查询拆分下推到各 worker 节点。类比：不拆房子重建，而是给现有房子加一个”智能管家”，管家负责把大任务拆成小任务分配给各个房间处理。

双协议兼容模式（YugabyteDB）：底层是 DocDB（基于 RocksDB + Raft），上层同时暴露 YSQL（兼容 PostgreSQL）和 YCQL（兼容 Cassandra）两套 API。类比：一个翻译官同时会两种语言，不管你说中文还是英文，他都能准确理解并处理你的请求。

PG 内核原生 + HTAP 双引擎模式（OpenTenBase）：基于 Postgres-XL 架构做 HTAP 增强——保留 PostgreSQL 完整内核，GTM（全局事务管理器）保证分布式事务一致性，Coordinator 做查询路由，Datanode 做数据存储，同时支持行存和列存引擎。类比：把一所学校的教室重新组织——校长办公室（GTM）统一管理课表和考试安排，年级主任（Coordinator）把学生分到不同教室（Datanode），每个教室既能上理论课（行存 TP）也能上实验课（列存 AP）。OpenTenBase 的差异化在于：既保持了 PostgreSQL 原生内核的完整生态兼容，又通过双存储引擎实现了 HTAP 能力，定位在 PG 生态与 HTAP 能力的交叉点上。

兼容协议对比

项目	MySQL 兼容	PostgreSQL 兼容	Cassandra 兼容	协议层实现方式
TiDB	✓（核心）	-	-	自研 SQL 解析器
CockroachDB	-	✓（核心）	-	自研 SQL 解析器
Vitess	✓（核心）	-	-	代理转发到真实 MySQL
Citus	-	✓（原生）	-	PostgreSQL 扩展，天然兼容
YugabyteDB	-	✓	✓	双 API 层（YSQL + YCQL）
OpenTenBase	-	✓（原生内核）	-	基于 PostgreSQL 内核，天然兼容

MySQL 阵营：TiDB 和 Vitess。PostgreSQL 阵营：CockroachDB、Citus、YugabyteDB、OpenTenBase。PG 阵营项目更多，反映了 PG 在分布式场景的生态优势。

架构模式对比

项目	架构类型	计算存储分离	自动分片	需要外部依赖
TiDB	原生分布式	✓（tidb-server / TiKV / TiFlash）	✓	PD 调度器（内建）
CockroachDB	原生分布式	-（每节点存算一体）	✓	无
Vitess	中间件代理	✓（VTGate / MySQL 实例）	手动定义分片规则	MySQL + etcd/ZooKeeper
Citus	PG 扩展	-（扩展运行在 PG 进程内）	半自动（需声明分布列）	PostgreSQL
YugabyteDB	原生分布式	-（每节点存算一体）	✓	无
OpenTenBase	协调-数据节点	✓（Coordinator / Datanode / GTM）	需声明分布策略	PostgreSQL 内核

HTAP 能力对比

项目	TP（事务处理）	AP（分析处理）	HTAP 实现方式	实时性
TiDB	TiKV（行存）	TiFlash（列存）	Raft Learner 异步复制行存→列存	秒级延迟
CockroachDB	✓	有限（无独立列存）	单一行存引擎	-
Vitess	✓（底层 MySQL）	有限（依赖 MySQL 能力）	无独立 AP 引擎	-
Citus	✓	✓（分布式聚合下推）	列存扩展（cstore_fdw）	批量
YugabyteDB	✓	有限（无独立列存）	单一 DocDB 引擎	-
OpenTenBase	✓（行存引擎）	✓（列存引擎）	内建双存储引擎，同节点行列共存	实时

真正具备完整 HTAP 能力（独立 TP + AP 引擎）的是 TiDB 和 OpenTenBase。CockroachDB、Vitess、YugabyteDB 偏 TP 方向，AP 能力有限。

代码量级对比

TiDB (tidb+tikv+pd):      ~5,000+ files（Go + Rust，多仓库）
CockroachDB:               ~15,000+ files（Go，单体大仓库）
Vitess:                    ~3,500+ files（Go）
YugabyteDB:                ~10,000+ files（C/C++/Java）
Citus:                     ~1,000+ files（C，PG 扩展相对精简）
OpenTenBase:               ~3,000+ files（C，基于 PostgreSQL 内核）

Citus 代码量最小，作为 PG 扩展专注于分布式查询层逻辑，通读成本最低。CockroachDB 单仓库代码量最大，但文档和测试覆盖极好。

学习价值排序

从”理解分布式数据库设计”的角度：

TiDB — 赛道标杆（41K star），HTAP 架构最完整，中文社区活跃，文档丰富，存储层 TiKV 是 Raft 共识算法的经典实现
CockroachDB — Spanner 设计的最佳开源实现，理解”全局一致性分布式事务”的必读项目，代码质量极高
Citus — 代码最精简，理解”如何用扩展方式实现分布式”，PG 生态的典型做法
Vitess — 理解”中间件模式”的代表，YouTube 大规模验证，CNCF 毕业项目
OpenTenBase — 理解”Coordinator-Datanode 架构”和”PG 内核 HTAP 改造”，国内大厂生产验证，PG 生态 + HTAP 双优势
YugabyteDB — 双协议兼容的设计取舍值得了解，但 C++ 代码量大，通读成本高

分布式数据库 开源项目全景对比