选数据库的时候，我们究竟在选什么 —— 当基础能力都满足时，哪些维度让数据库"脱颖而出"

本文是「PostgreSQL 系列」的视角篇 · 二。配套源码版本：PostgreSQL 18 dev（~/cwork/postgresql）。同系列前文：

• 当我们在说”数据库”的时候，我们到底在说什么 —— 从用户的视角拆解 PostgreSQL 的能力与接口
• PostgreSQL 事务：一次 BEGIN 与 COMMIT 背后的双层世界
• PostgreSQL MVCC：从一行 UPDATE 到 5 个 HeapTuple 的演化
• PostgreSQL 内存管理：从 shared_buffers 到内存上下文
• PostgreSQL 分区表：从一行 PARTITION BY 到路由热路径

上一篇我们列了 PG 给你的 5 + 7 + 8 张清单——能存能取、能查能改、能事务能复制能扩展。但这其实是**所有数据库都能给到你的”地板能力”**。MySQL 能、Oracle 能、SQL Server 能、MongoDB 能（某种程度）、甚至 SQLite 都能。

那么问题来了——

当所有数据库都能做”基础动作”时，为什么有的数据库就能脱颖而出，被百万人选择？

答案藏在”地板之上”的 7 个维度里。本文的目的就是把这 7 个维度讲透——让你在下一次选型时，能问出正确的问题，而不是被销售演示里的”TPS 百万 / 毫秒延迟 / 千亿行”忽悠。

一、先想清楚：选数据库到底在选什么

1.1 一次真实选型会踩的坑

这是大多数人选型的真实过程：先问”多大数据 / 多高 QPS”，再问”分析还是事务”。但这种问法漏掉了真正决定长期走向的 7 个维度。下面一一展开。

1.2 一个反直觉的事实：基础能力不是差异点

让我列一组”所有数据库都能给”的能力清单：

你会发现：任何一个进入”主流”的数据库，都把这 9 项做到 80 分以上。差异不在这些”标配”上，而在它们怎么做、做到什么代价。

二、维度 1：架构模型 —— 单节点 vs 分布式

这是最最最重要的维度，但很多人忽略它。

2.1 三种基本架构

三种架构的取舍：

2.2 单节点数据库的”实际上限”

单节点 PG / MySQL 在生产环境能扛多少？粗略数据：

超出这些上限，就是分布式数据库的领域——而分布式带来的复杂度不是线性增长，是指数。

2.3 分布式数据库的两条技术路线

路线 A ——“看起来像 PG / MySQL 的分布式版本”：

• 代表：CockroachDB（PG 协议）、TiDB（MySQL 协议）、YugabyteDB
• 优势：应用代码几乎不用改，迁移成本低
• 代价：跨分片 join 性能差（O(N²) 数据交换）、事务延迟高、运维模型与传统 DBA 不一致

路线 B ——“云数仓路线”：

• 代表：Snowflake、BigQuery、Databricks SQL、Redshift
• 优势：存算分离、各自扩展、PB 级分析秒级响应
• 代价：写延迟较高（秒级）、不擅长 OLTP、按扫描字节收费

PG 用户最常问的”什么时候该上 CockroachDB / TiDB”：答案是写 QPS 已经超过单 PG 实例的 50%（约 5 万）+ 数据量已经超过单 PG 实例的 80%（约 8 TB）+ 业务上明确不需要大量跨表 join。否则，单 PG + 读写分离 + 分区表仍然是更划算的选择。

三、维度 2：存储引擎 —— 行存 vs 列存、BTree vs LSM

存储引擎决定了数据库的 I/O 模型，是 OLTP vs OLAP 分化的最底层原因。

3.1 行存 vs 列存的本质

行存 vs 列存的真实数据：

结论：OLTP 选行存、OLAP 选列存。想要一个数据库通吃？HTAP（见 §五）。

3.2 索引结构：BTree vs LSM

PG 用的是 BTree（默认索引）—— 这意味着：

• ✅ PG 擅长读多写少的场景
• ⚠️ PG 不擅长超高写入场景（每秒几十万 INSERT 走 BTree 会卡）
• ❌ 想要列存做 OLAP，PG 得装 citus_columnar 插件或外接 ClickHouse

3.3 一句话总结存储引擎

存储引擎决定了数据库的”肌肉类型”：BTree 像马拉松选手（持久稳定）、LSM 像短跑运动员（爆发强但抖动）、Column 像举重选手（一次性扛很多）。没有最好，只有最合适。

四、维度 3：一致性模型 —— 强一致 vs 最终一致

CAP 三角告诉你：一致性 (C)、可用性 (A)、分区容忍 (P) 只能三选二。

4.1 现实里数据库的一致性档位

4.2 “一致性的真实代价”

一个朴素但关键的问题：你的业务能不能容忍”看到旧数据 5 秒”？

• 能 → 最终一致的 Cassandra / MongoDB 没问题，省事省钱
• 不能 → 必须 PG / MySQL / CockroachDB（同步复制）

很多公司花大价钱上 CockroachDB / TiDB，结果发现业务根本用不到强一致——这是用大炮打蚊子。

4.3 真实案例：一致性错配的代价

案例 A：某电商公司在 MongoDB 上做订单系统，5% 的订单出现重复扣款——因为 MongoDB 4.0 之前不支持跨文档事务。

案例 B：某社交 App 在 Cassandra 上做点赞数统计，每天有几万条点赞丢失——最终一致性的代价。

案例 C：某金融机构用 Redis 做账户余额主存储，系统宕机后丢了几百万元数据——内存数据库不能保证持久性。

反向案例：某互联网公司用 PG 做消息推送记录，一年几亿条，从来没问题——因为业务可以容忍秒级延迟。

4.4 如何选择一致性级别

一个经验法则：金融、订单、库存 = 强一致；社交 feed、日志聚合、点赞 = 最终一致；中间地带（用户资料、订单查询）= PG 流复制同步半秒延迟。

“。

五、维度 4：优化目标 —— OLTP vs OLAP vs HTAP

**这一维度决定了数据库”是谁的菜”**——业务系统、数据分析系统、还是两者都要。

真实数据：OLTP vs OLAP 的差异：

HTAP 的本质：把 OLTP 和 OLAP 跑在同一份数据上，避免 ETL 链路。但代价是：

• 同时承担两种 workload，资源争抢严重
• 通常 OLTP 性能不如纯 OLTP DB
• OLAP 性能不如纯 OLAP DB

我的建议：99% 的场景下不要选 HTAP。OLTP 数据 → ETL → OLAP 数仓更划算。HTAP 只在”实时报表 + 强一致”才有意义。

六、维度 5：生态、工具链、人才市场

这是被严重低估的维度——技术参数都差不多时，生态决定一切。

6.1 6 个数据库的”生态版图”

6.2 生态的 4 个隐性指标

为什么生态比性能重要：

• 招不到 DBA → 性能再好也跑不起来
• 出问题搜不到答案 → 凌晨 3 点你独自 debug
• 升级路径不清晰 → 几年后被锁死
• 工具链不全 → 备份、监控、迁移全靠自己写

PG 在生态上的现状：

• ✅ 开源、协议友好（BSD）、社区活跃
• ✅ 文档质量顶级
• ✅ Stack Overflow 排名前 5
• ⚠️ DBA 招聘比 MySQL 难
• ✅ 扩展生态最丰富（PostGIS、pgvector、TimescaleDB、Citus…）

七、维度 6：商业模型与许可证

这一维度决定了 3 年后你还在不在用这个数据库。

7.1 主流数据库的许可证

7.2 许可证的”长期影响”

MongoDB 在 2018、Redis 在 2024 把许可证改成 SSPL——核心动机是阻止 AWS / 阿里云 / 腾讯云等”白嫖”自家开源软件。这对企业用户意味着：用 SSPL 数据库部署 SaaS 服务 = 违法。

3 个具体场景：

八、维度 7：运维成本

DBA 招不到 / 不会用 = 数据库等于没有。这一维度直接决定 TCO（总拥有成本）。

8.1 运维成本的 6 个组成

8.2 各数据库的运维成本对比（粗略）

Oracle 的 TCO 真相：年授权费 + 年支持费 = 数据库本身费用的 2~3 倍。一个 100 万的 Oracle 部署，5 年 TCO 约 500 万。**PG 的 TCO 基本只有硬件 + DBA 工资。

8.3 5 个被忽视的软成本

5 个软成本的具体数字（基于行业经验）：

结论：选数据库时只算硬件 + 授权是新人思维。把 DBA、迁移、停机、合规都算上才是真正的 TCO。

**。

九、把 7 个维度串起来：选型决策树

十、6 个常见数据库的”灵魂对比”

把市面上最常被选到的 6 个数据库按”差异化定位”对比：

10.1 PostgreSQL vs MySQL：永恒之争

选择规则：

• 复杂业务逻辑、报表、JSON、向量 → PG
• 读多写少、Web 后端、DBA 资源少 → MySQL
• 不确定 → PG（能力上 PG 包含 MySQL 的子集）

十一、为什么”分布式”是真正的分水岭

**绝大多数选型失败，都不是因为”功能不行”，而是因为”低估了分布式的代价”**。

11.1 分布式带来的 5 个真实问题

11.2 分布式数据库的”不可承受之轻”

我的建议：先用单节点 PG 走到单实例极限，再考虑分布式。大多数公司永远不会到那个极限。

11.3 分布式的伪命题：很多场景根本不需要

为什么 95% 的公司不需要分布式：

• 真实写 QPS > 5 万的业务，国内只有 0.1% 的公司
• 数据 > 10 TB 的公司，99% 都是日志/事件，该用 ClickHouse 而不是分布式 RDBMS
• 强一致 + 高可用 + 大数据 = 成本极高（看看各家分布式 DB 的 license fee）

Citus 渐进式扩展：PG 官方扩展，把单节点 PG 变成 shared-nothing 集群，无须换数据库：

-- 在 PG 上装 Citus
CREATE EXTENSION citus;

-- 把表变成分布式
SELECT create_distributed_table('orders', 'customer_id');

-- 应用代码基本不改
SELECT count(*) FROM orders WHERE customer_id = 1;  -- 路由到对应节点

Citus 是单节点 PG → 分布式 PG 的最平滑路径。

十一·五、为什么 PostgreSQL 是全能型中等生的代表

PG 是 6 个维度 80 分 + 2 个维度 90 分 + 4 个维度 70 分的数据库——没有任何一项是绝对第一，但没有一项严重短板。这就是全能型中等生的本质。

反例：Oracle 在单节点性能、商业支持 95+ 分，但生态封闭 / 协议不友好 / TCO 高 —— 30 分短板。Cassandra 在分布式 / 写扩展 95 分，但事务 / 一致性 30 分 —— 也是短板。

全能型数据库的优势：技术栈统一。一个 PG 可以覆盖 80% 的业务（OLTP + JSON + 时序 + 全文 + 向量），剩下的 20% 用专用 OLAP（ClickHouse）+ 专用搜索（ES）+ 专用缓存（Redis）补足。这才是 5 个数据库搞定一切的真相，不是一个数据库搞定一切。

十二、为什么”OLAP 加速器”成为新热点

过去 5 年数据库领域最大的趋势：专门做 OLAP 的列存数据库爆发。代表：ClickHouse、DuckDB、Snowflake、Databricks。

为什么 OLAP 数据库崛起：

• 物联网 / 移动 App 让日志量暴增 100 倍
• 业务方要求”实时报表”（分钟级延迟），传统 ETL 太慢
• 列存压缩比高（10x），存储成本降 90%
• 算力成本降 90%，扫描 PB 数据不再是奢侈品

ClickHouse / DuckDB / Snowflake 的差异：

PG 用户怎么接 OLAP：

两条常见路径：

1. PG → 逻辑复制 → ClickHouse：5 分钟配置，立即查询
2. PG → Kafka → Flink → ClickHouse：复杂 ETL 场景

十二·五、近 5 年数据库领域 5 个明显的趋势

趋势 1：OLAP 列存爆发

代表：ClickHouse（2016 开源，2024 估值 $6B）、DuckDB（2019 开源，嵌入式 OLAP 之王）、Snowflake（市值峰值 $250B）。

驱动因素：

• 物联网 + 移动 App 产生 PB 级日志
• 业务方要实时报表，传统 ETL 跟不上
• 列存压缩比高 10x，存储成本降 90%

趋势 2：PG 生态扩张

代表：pgvector（向量检索）、PostGIS（地理信息）、TimescaleDB（时序）、Citus（分布式）。

驱动因素：PG 的扩展机制最友好——一个 SQL + 一个 Makefile 就能造一个新数据库。

具体数字：

• pgvector 在 GitHub 12k+ stars
• PostGIS 是开源地理信息事实标准
• TimescaleDB 把 PG 变成时序 DB（比 InfluxDB 强 SQL 兼容性）
• Citus 把 PG 变成分布式

趋势 3：云数仓崛起

代表：Snowflake、BigQuery、Databricks SQL、Redshift、阿里云 MaxCompute。

核心特征：存算分离、SaaS 化、按扫描字节付费。

对传统数仓的冲击：Teradata、Oracle Exadata、IBM Netezza 市场份额快速下滑。

趋势 4：License 收紧

事件：

• MongoDB 2018：从 AGPL 改 SSPL
• Redis 2024：从 BSD 改 SSPL + RSAL
• CockroachDB：从 BSL 改 Apache 2.0（反向操作）

对用户的影响：用 SSPL 数据库做 SaaS = 违法。

趋势 5：HTAP 务实化

代表：TiDB（PingCAP）、Singlestore（前 MemSQL）。

真实用户：相对 OLTP + OLAP 双 DB，HTAP 用户少得多。但在”实时大屏 + 强一致”场景有真实需求。

十三、回到选型：5 步走框架

13.1 Step 1 —— 业务定性

回答 4 个问题：

1. QPS 量级：100？1 万？10 万？100 万？
2. 数据量级：GB？TB？PB？
3. 一致性需求：强一致？最终一致？
4. 事务复杂度：简单 CRUD？复杂业务逻辑？

13.2 Step 2 —— 架构选型

13.3 Step 3 —— 引擎选型

13.4 Step 4 —— 生态评估

5 个体检指标：

1. DBA 招聘 JD 数量：决定未来 3 年运维难度
2. Stack Overflow 问答数：决定凌晨 3 点能否搜到答案
3. 第三方工具支持：决定备份 / 监控 / 迁移能否省力
4. 官方文档质量：决定新人上手速度
5. 社区活跃度：决定 3 年后还在不在维护

13.5 Step 5 —— 长期 TCO

3 年 TCO = 硬件 + 授权 + DBA × 3 + 故障 × 估时 + 迁移代价

十四、3 个真实选型案例

14.1 案例 1：电商 OLTP

业务：日 1 亿订单，单库数据 5 TB，复杂促销逻辑。

错选：ClickHouse（不能做事务）
错选：MongoDB（事务弱）
错选：Oracle（成本）
正确：PG + 分区表 + 读写分离 + Redis。

14.2 案例 2：用户行为分析

业务：日 100 亿事件，查询”过去 7 天每个城市每小时的点击量”。

错选：PG（聚合太慢）
正确：ClickHouse + Kafka。

14.3 案例 3：AI 应用向量检索

业务：1000 万文档，向量相似度查询，要求 PG 兼容。

错选：Milvus（增加新数据库）
正确：PG + pgvector 扩展——一个 DB 两用。

CREATE EXTENSION pgvector;
CREATE TABLE docs (
  id bigserial PRIMARY KEY,
  embedding vector(1536)
);
CREATE INDEX docs_hnsw ON docs USING hnsw (embedding vector_cosine_ops);

-- 查询
SELECT id FROM docs ORDER BY embedding <=> $1 LIMIT 10;

十四·五、3 个真实的选型失败案例

失败案例 1：用分布式数据库解决单节点问题

某 SaaS 公司，业务 QPS 1 万（单 PG 完全够），但 CTO 听说分布式是趋势，就上了 CockroachDB。3 个月后：

• 应用代码改写 50%
• DBA 不熟悉 CockroachDB，故障排查靠官方文档
• 性能反而比单 PG 慢 30%
• License fee 是 PG 的 5 倍

教训：分布式是工具，不是潮流。

失败案例 2：用 OLTP 数据库做 OLAP

某零售公司，用 Oracle 做 BI 报表。每天扫 100 GB 数据：

• 报表查询跑 30 分钟
• 阻塞线上交易
• 月底报表出来慢 1 天

正确做法：Oracle 做 OLTP + ClickHouse 做 OLAP，ETL 用 pg_dump 或 kafka。

失败案例 3：用 MongoDB 做订单系统

某电商公司，初期业务快，flexible schema 吸引 CTO 用 MongoDB。3 个月后：

• 跨文档事务不支持
• 订单重复扣款率 2%
• 库存超卖
• 最后花 6 个月迁回 MySQL

教训：文档数据库不是 RDBMS 的替代品，是补充品。

十五、回到标题：选数据库到底在选什么

回答标题：选数据库时，选的不是”最快”或”最大”，而是”最匹配你的 7 个维度权衡”的那个。

数据库没有银弹，只有最合适的权衡。

回到开头那个朴素问题：”为什么有的数据库能脱颖而出？”

答案是：

不是因为它”性能最强”或”功能最多”，而是因为它对某个特定场景的 7 个维度权衡，做出了最契合那个场景的选择。

PostgreSQL 脱颖而出，是因为它在”功能完整 + 单机性能 + 强一致 + 开源 + 生态 + 扩展性” 这 6 个维度同时打 80 分——成为”全能型中等生”。

ClickHouse 脱颖而出，是因为它在”列存 OLAP + 实时写入 + 分布式” 这 3 个维度打 95 分——成为”OLAP 之王”。

Snowflake 脱颖而出，是因为它把”云数仓 + 存算分离 + 按需付费” 这 3 个维度组合到一个新形态——创造了”云数仓”品类。

它们都选了不同的 7 维度组合，所以都成功了。

PostgreSQL 脱颖而出

它们都选了不同的 7 维度组合，所以都成功了

十六、给读者的 3 个忠告

16.1 不要相信”TPS 百万”

任何数据库厂商给你看 “TPS 百万” 的 demo，都在理想条件下：

• 单行简单 INSERT
• 内存全装得下
• 无并发争抢
• 无持久化

真实场景下打 1 折都算好的。要问的是”在我的业务场景下，TPS 是多少”——做 POC 实测，别看 demo。

16.2 不要低估运维成本

真实故事：某创业公司选型时只看性能，上了 Cassandra。3 年后：

• 业务量没增长，但运维成本涨 3 倍
• DBA 全跑了（招不到新 DBA）
• 不得不花 200 万迁回 PG

教训：性能再好，DBA 招不到 = 数据库等于没有。

16.3 不要把”未来扩展性”当现在问题

真实故事：某公司当前数据 1 GB，但 CTO 说”我们要考虑未来 1 PB”，就上了 CockroachDB。3 年后：

• 业务还在 1 GB
• CockroachDB License fee 每年 50 万
• 单 PG 完全够用

教训：先解决今天的问题，3 年后再解决 3 年后的问题。数据库迁移比想象中容易——只要数据能用 pg_dump / mysqldump 出来。

十七、最后的最后：选数据库 = 选一种工程哲学

每个数据库背后都是一种工程哲学：

• PostgreSQL：开放、扩展、用户自治
• MySQL：简单、可靠、广泛使用
• Oracle：极致、企业级、商业闭环
• ClickHouse：单一目标做到极致
• Snowflake：云原生、按需付费

你选的不是技术，是哲学。

所以——回到标题问题——选数据库到底在选什么？

选的是一种你认为值得长期投入的工程哲学。

5 年后你还在用哪个数据库，取决于 5 年前你信了哪种哲学。

十六、参考资料

同系列前文

• 当我们在说”数据库”的时候，我们到底在说什么 —— 从用户的视角拆解 PostgreSQL 的能力与接口
• PostgreSQL 事务：一次 BEGIN 与 COMMIT 背后的双层世界
• PostgreSQL MVCC：从一行 UPDATE 到 5 个 HeapTuple 的演化
• PostgreSQL 内存管理：从 shared_buffers 到内存上下文
• PostgreSQL 分区表：从一行 PARTITION BY 到路由热路径
• PostgreSQL 逻辑复制表的生命周期：从 pg_replication_slots 到 pg_subscription_rel

推荐阅读

• CAP 定理：Eric Brewer, “Towards Robust Distributed Systems”, 2000
• 分布式数据库：Daniel Abadi, “The End of Architectural Era”, 2007（HStore/C-Store 论文）
• 列存数据库：Mike Stonebraker et al., “C-Store: A Column-oriented DBMS”, 2005
• HTAP：TiDB / Singlestore 官方文档
• 许可证对比：MariaDB Foundation / OSI / SSPL 官网

选型参考链接（截至 2026）

• DB-Engines Ranking: https://db-engines.com/en/ranking
• ClickHouse 官方文档：https://clickhouse.com/docs
• CockroachDB 文档：https://www.cockroachlabs.com/docs
• TiDB 文档：https://docs.pingcap.com