2026 年 ClickHouse 的替代方案:带表格的诚实对比
发布于:
阅读时间: 4 min
主题: 技术
作者: Leandro Valencia
DuckDB、StarRocks、Druid、Pinot、TimescaleDB、BigQuery 等。对 ClickHouse 替代方案的真实比较,带表格和按用例的推荐。
目录
怎么评估一个分析数据库(真正重要的标准)
在表格之前,先把轴定下来。我见过太多人按 benchmark 选、又因为运维后悔的。
真实运维成本。 不是许可证价格——大多数是开源的——而是你每个月要花多少小时保它活着。这是单干时权重最大的标准,也是对比文章里最看不见的标准。
部署模式。 一个二进制?一个六种进程的集群?只能用云托管?这决定了你能不能在一台 20 欧的 VPS 上起步,还是需要 Kubernetes。
摄入延迟。 一个事件多久之后能被查到?秒、分钟还是小时。只有你真的需要实时的时候才重要;很多人以为自己需要,其实并不。
并发。 能扛多少同时查询?做面向客户的产品内分析时是关键;如果是三个内部人看的 dashboard,无关紧要。
规模化时的成本模型。 按消费计费(BigQuery、Snowflake)对比固定服务器(自托管 ClickHouse)。前者在用量低时很美好,在有人开着 dashboard 自动刷新时很恐怖。
生态和驱动成熟度。 如果你栈是 Python 或 Node,有没有官方客户端?连 Metabase 或 Grafana 痛不痛苦?
对比表
读这张表时请知道,每个单元格都是简化,细节在后面的小节里。
| ClickHouse | DuckDB | StarRocks | Apache Druid | Apache Pinot | TimescaleDB | BigQuery / Snowflake | |
|---|---|---|---|---|---|---|---|
| 类型 | 分布式列式 OLAP | 嵌入式(进程内)OLAP | 列式 MPP OLAP | 实时 OLAP | 实时 OLAP | PostgreSQL 扩展 | 托管云数仓 |
| 协议 | Apache 2.0 | MIT | Apache 2.0 | Apache 2.0 | Apache 2.0 | Apache 2.0 / TSL | 专有 |
| 最小部署 | 1 个二进制 | 1 个库 | Frontend + Backend 节点 | 6 种进程 + ZooKeeper | Controller、Broker、Server + ZooKeeper | Postgres + 扩展 | 仅 SaaS |
| 运维难度 | 低—中 | 无 | 中 | 高 | 高 | 很低 | 无(你付钱) |
| 聚合查询性能 | 极佳 | 极佳(单节点) | 极佳 | 很好 | 很好 | 好 | 好—很好 |
| 复杂 JOIN | 很好 | 极佳 | 极佳(它的强项) | 有限 | 有限(在改善) | 极佳(它是 Postgres) | 极佳 |
| 流式摄入 | 好(Kafka engine、MV) | 不适用 | 好 | 极佳 | 极佳(它的强项) | 好 | 中(批次优先) |
| 摄入—查询延迟 | 秒 | 不适用 | 秒 | 亚秒 | 亚秒 | 即时 | 分钟 |
| 高并发 | 很好 | 低(一个进程) | 很好 | 好 | 极佳 | 中 | 好但贵 |
| UPDATE / DELETE | 有限(轻量 mutation) | 是 | 是(它的强项) | 非常有限 | 非常有限 | 完整 | 是(代价高) |
| SQL 方言 | 自有,大幅扩展 | Postgres 兼容 | MySQL 兼容 | 自有 SQL | 自有 SQL | 纯 PostgreSQL | 标准 SQL |
| 实用规模 | TB—PB | GB—几百 GB | TB—PB | TB—PB | TB—PB | GB—几十 TB | PB |
| 成本模型 | 固定服务器 | 免费(跑在你的进程里) | 固定服务器 | 固定服务器(贵) | 固定服务器(贵) | 固定服务器 | 按消费 |
| 对单干独立开发者的契合度 | ✅ 是 | ✅ 是 | ⚠️ 要花力气 | ❌ 否 | ❌ 否 | ✅ 是 | ⚠️ 账单风险 |
逐项分析
DuckDB —— 更多人应该最先考虑的对手
DuckDB 是一个进程内分析数据库:没有服务器,作为库跑在你的应用里,就像分析版 SQLite。pip install duckdb 你就拿到一个向量化列式引擎。
明确赢的地方: 绝对的简洁。零运维、零端口、零备份要配。直接查 Parquet 和 CSV,原生集成 pandas 和 Polars,SQL 方言兼容 PostgreSQL,所以你不用学新语法。对本地数据分析、notebook、ETL、或小型应用的分析后端,很难被打败。
输的地方: 它本质上是一个进程。不为几十个并发用户提供数据,不水平扩展,不是为接收多源持续写入的共享服务设计的。如果你需要那些,MotherDuck 作为云层存在,但那时你已经进入另一种模型了。
我的看法: 如果你的数据集装得下一块磁盘,而查询是你的后端或你自己从 notebook 发起的,先从 DuckDB 起,而不是 ClickHouse。这是大家最抗拒、又最常是对的推荐。复杂度是"没有它就会痛"的时候才加上去的。
实用的边界是你需要一个服务而不是一个库的时候:多个写入方、多个并发读取方、数据在一台机器上放不下、要保留数年。那里你跨到 ClickHouse。
StarRocks —— 如果你的数据是规范化的,认真的替代
StarRocks 是一个列式 MPP 数据库,与 ClickHouse 共享很多理念,但在两个关键点上不同。
赢的地方: 多表 JOIN 和实时更新。StarRocks 从一开始就假定你会查询规范化的星型 schema,有一个成熟的、基于成本的 JOIN 重排优化器。如果你来自传统数仓、有事实表和维度表、又不想全部反规范化,它更合适。它还兼容 MySQL 协议,意味着任何 MySQL 客户端都能不用特殊驱动就连上。
输的地方: 生态和社区比 ClickHouse 小。现成的集成少,半夜两点出问题时 Stack Overflow 上的答案少,已经熟悉它的工程师少。而且最小安装涉及两种节点(frontend 和 backend),不是一个二进制。
我的看法: 它是技术上最能和 ClickHouse 对标的替代。如果你的负载是"很多 JOIN 和频繁更新的数仓",认真评估它。如果你的负载是"我按时间聚合的事件洪流",ClickHouse 仍然更简单、上线更快。
Apache Druid —— 强大但运维昂贵
Druid 多年在大规模做实时时序分析,而且做得好。它的架构是为从 Kafka 摄入并即时可查而精调的。
赢的地方: 亚秒延迟的流式摄入,以及"热"数据(近期、在内存)和"冷"数据(历史、在深度存储)之间的清晰分离。对于长期保留的大规模监控用例,这个设计是有道理的。
输的地方: 运维复杂度。Druid 需要 Coordinator、Overlord、Broker、Router、Historical 和 MiddleManager,加上协调用的 ZooKeeper 和 metadata store。这是六种进程加两个外部依赖。它是一个需要专职人员的集群。而且 JOIN 仍是它的弱项,数据模型也较不灵活。
我的看法: 对独立开发者或小团队,Druid 直接不可行。不是因为技术差——它不差——而是因为它的运维成本除非在非常大的规模上,否则摊不回来。值得一提的是,包括 Lyft 在内的几家知名公司都以"降低成本、简化架构"为由,从 Druid 迁到了 ClickHouse。
Apache Pinot —— 面向用户分析之王
Pinot 出生于 LinkedIn,为给数亿用户提供"谁看了你的资料"。这种 DNA 很明显:它针对超高并发下的毫秒延迟做了优化。
赢的地方: 如果你在产品里做一个分析功能,几千用户同时查、延迟 SLA 严格,Pinot 有最专门为此设计的架构。星型索引、倒排索引、为这种模式调优的分区。
输的地方: 和 Druid 一样,运维复杂度高(Controller、Broker、Server,加 ZooKeeper)。对探索性即席查询不够灵活:它在你事先知道查询模式、能为它们建索引时发光,而不是在你想探索时。
我的看法: 对一个很具体、而小项目几乎没有的问题来说,是优秀工具。如果你不是在给超过一千个并发用户提供分析,ClickHouse 用 20% 的复杂度给你 90% 的结果。
TimescaleDB(TigerData)—— 不强迫你迁移的替代
TimescaleDB 是 PostgreSQL 针对时序的扩展。2025 年 6 月公司改名为 TigerData,但开源扩展仍叫 TimescaleDB。
赢的地方: 它就是 PostgreSQL。你的全部知识、你的驱动、你的工具、你的备份、你的 ORM、你和应用表的 JOIN,全部继续工作。它加上"hypertable"(按时间自动分区)、连续聚合和列式压缩。而且因为是 Postgres,你有完整 ACID 事务和无痛的 UPDATE/DELETE。
输的地方: 在超大体量聚合上的性能不在 ClickHouse 那个级别。它底下还是 Postgres,带着一个用列式压缩打补丁的行式引擎的局限。在几十 TB 上,差距很明显。
我的看法: 被追新的人低估了。如果你已经在用 Postgres、数据是时序、问题是几十或几百 GB 而不是 TB,TimescaleDB 大概是你能做的性价比最高的决定。你用一个扩展而不是一个新服务做迁移。你不加的复杂度,就是你不用维护的复杂度。
BigQuery 和 Snowflake —— 零运维,账单可变
托管云数仓彻底消除运维问题。没有服务器,没有升级,没有备份。你写 SQL,然后付钱。
赢的地方: 几乎无限扩展而不用想基础设施,与云生态其他部分深度集成,以及在数据治理、权限和合规上巨大成熟度。如果你是一家有预算、希望团队专注业务的公司,这是一个说得过去的决定。
输的地方: 定价模型。你按扫描数据量(BigQuery)或计算时间(Snowflake)付钱,而两种模型都正好惩罚交互式分析的典型模式:大量频繁的小查询。每 30 秒自动刷新的 dashboard 可能产生不成比例的账单。而且查询延迟很少降到几百毫秒到秒以下,使它们不适合嵌入到产品里的分析。
我的看法: 对 bootstrap 的项目,账单可变的风险是业务风险,不是技术风险。我见过 BigQuery 成本超过其他所有基础设施加在一起的项目。一台用 ClickHouse 的专用服务器成本已知且平稳,这在你的账单不多时很有价值。合理例外:如果你的数据已经在 Google Cloud、查询量低且零星,BigQuery 可能比维护一台服务器更便宜。
特别提名:Apache Doris 和 Tinybird
Apache Doris 和 StarRocks 非常相似(同源),出于同样理由值得一看。Tinybird 是建在 ClickHouse 之上的托管层,在你的查询上加 API——如果你想要 ClickHouse 又不想运维、还想加一层产品,值得一试。
结论:按你的情况选什么
把上面翻译成具体推荐。
你在 notebook 里探索数据,或不到 50 GB —— DuckDB。 没得讨论。零运维、出色性能、熟悉的 SQL。
你已经在用 PostgreSQL,数据是时序的,量级是几十 GB —— TimescaleDB。 你加的是一个扩展而不是一个服务。最无聊、大概也最正确的选项。
你有事件洪流、想自托管、单干或小团队 —— ClickHouse。 性能和运维复杂度的最佳点。VPS 上的一个二进制能扛下大多数项目永远用不到的量。
你在产品里给几千并发用户做分析 —— 先 ClickHouse,不够再 Pinot。 从简单开始;只有 SLA 真的需要时才迁。
你的 schema 是个带很多 JOIN 和更新的规范化数仓 —— StarRocks。 它的 JOIN 优化器是它对 ClickHouse 的真正优势。
你有预算、有团队、想要零基础设施 —— BigQuery 或 Snowflake。 从第一天就设好成本告警。
你需要超大规模的亚秒摄入、有专职 SRE —— Druid 或 Pinot。 如果你没有专职 SRE,这一行不是给你的。
我选错后学到的东西
我有两次选了最强大的工具而不是最合适的,两次都付了代价。
第一次,我给一个有 1200 万行的项目搭了个集群。1200 万。DuckDB 本来能从一个文件毫秒级回答那些查询。我花了一个周末配置了一个解决我并没有的问题的东西。
第二次我按 benchmark 选。数据库 benchmark 测的是实验室条件下的查询延迟;它们测不出你会花多少小时调试摄入,也测不出社区小到你的错误哪儿都搜不到有多痛。一个数据库的真实成本是它偷走你的时间,而不是它替你省下的毫秒。
我现在的标准,按顺序:第一,选能解决你今天问题的最简单选项;第二,验证它有清晰的退路(你能导出成 Parquet 吗?);第三,只有那时候才看性能。如果最简单的选项在一年内撑不住,你到时候再迁——而到那时你会更清楚自己需要什么。
结论
没有"最好的 OLAP 数据库"。只有对你的数据量、你的团队、你的预算最好的那一个,而对大多数小项目,这个答案是 DuckDB 或 ClickHouse,而不是更复杂的选项。
ClickHouse 在这个图景里占据一个非常特殊的位置:分布式系统的性能,加上单体应用的运维复杂度。这种组合很罕见,这也是为什么当项目已经长到超过 DuckDB 能给的,它仍然是我的默认选项。
如果你已经决定用 ClickHouse,下一步是真正把它用好:ClickHouse 进阶指南 讲物质化视图、projection、编码,以及把平庸的 ClickHouse 和快的 ClickHouse 区分开的一切。如果你还没装,先看 ClickHouse 是什么、怎么安装。
常见问题
ClickHouse 最好的替代是什么?
看情况。装得下一台机器的数据集用 DuckDB,需要复杂 JOIN 和频繁更新用 StarRocks,已经在用 PostgreSQL 就用 TimescaleDB,优先最低延迟加超高并发就用 Apache Pinot。
ClickHouse 还是 DuckDB?
数据装得下一块磁盘、查询由单个进程发起,用 DuckDB。需要共享服务、多源并发写入、或要扩展到一台机器之外,用 ClickHouse。
ClickHouse 还是 BigQuery?
想要平稳可预测的成本和毫秒级延迟,用 ClickHouse;宁愿零运维、查询量低且零星、数据已经在 Google Cloud,用 BigQuery。
StarRocks 比 ClickHouse 好吗?
在多表 JOIN 和实时更新上,一般是。在部署简单、社区规模和集成生态上,ClickHouse 保持优势。
Apache Druid 在 2026 年还值得吗?
在有专职基础设施团队的非常大規模上,值得。对中小项目,它的运维成本很少能对 ClickHouse 证明自己。
相关文章
继续探索您可能感兴趣的相似内容
OLAP 数据库:是什么、真实用例和主要厂商
OLAP 数据库是什么、与 OLTP 有何不同、带真实 SQL 的实用案例,以及 2026 年的主要厂商。
ClickHouse 进阶指南:优化、物质化视图和真实技巧
如何把 ClickHouse 发挥到极致:ORDER BY、物质化视图、projection、编码、TTL、S3 分层和慢查询诊断。带真实 SQL。
ClickHouse 是什么:特点与一步步安装(2026 指南)
给独立开发者的 ClickHouse 实践指南:它是什么、为什么这么快、关键特性,以及如何用 curl 或 Docker 在 5 分钟内装好。