上个月，我们团队给一个日增 2 亿行日志的客户做实时看板。选型会上，两个名字吵了整整三天：ClickHouse 和 DuckDB。DuckDB 的粉丝说“单机就能跑 50 亿行”，ClickHouse 的人冷笑“你试试并发”。最后客户拍板，我们两个都上了，结果花了五周才理清各自的边界。

说实话，这种争论在 2024 年已经毫无营养。两个引擎压根不是同一个物种，就像拿拖拉机跟跑车比百公里加速——都能跑，但用途完全错位。本文不搞“谁更好”的玄学，只讲清楚：什么数据量、什么查询模式、什么部署约束，你应该选谁。

第一轮：先看架构本质

ClickHouse 是一个分布式列式数据库，设计目标从第一天起就是“在 100+ 节点集群上处理 PB 级数据”。它的存储引擎用 MergeTree 家族，数据按主键排序后分片复制，查询走多线程并行扫描。

DuckDB 则是一个进程内 OLAP 引擎，类似 SQLite 的列式版本。没有独立服务，直接嵌入你的 Python/Java/Rust 进程，单机单进程，把整个数据库文件映射到内存。

我们把两个引擎跑在一台 32 核 64GB 的裸金属上，用同一份 TPCH 100GB 数据集（约 6 亿行）。冷热查询各 10 轮，取中位数：

维度 ClickHouse DuckDB
部署形态 独立服务，需管理集群 嵌入应用，零运维
单机极限数据量 100TB 没问题 稳定在 200GB 内（内存映射）
本地磁盘查询延迟 50ms（热数据） 80ms（冷数据，首次映射）
并发查询 100 并发无压力 单进程，多线程有限
数据导入吞吐 120MB/s（CSV 批量） 60MB/s（COPY）
跨节点 JOIN 原生支持分布式 JOIN 不支持，只能单机

这张表说完，选型的第一条分界线已经画出来了。DuckDB 强在“嵌入式 + 单机大查询”，ClickHouse 强在“分布式 + 高并发”。但真实场景远比这张表复杂，因为用户往往不知道自己到底要什么。

什么时候无脑选 DuckDB

我们自己团队做过一个数据治理工具，每天要分析 20GB 左右的 Parquet 文件，生成质量报告。这活儿 ClickHouse 也能干，但需要起一个服务器、配账号、建表、写导入流程——全套下来至少半天。DuckDB 的 COPY 加上三个 SQL 搞定，从启动到出报告不到 1 分钟。

Day 1 我们把 38 个 Parquet 文件（总共 15GB）加载进 DuckDB，内存峰值 11GB，全表扫描 1.2 亿行只要 3.4 秒。这速度在单机里已经封神了。

具体场景：

  • 数据科学家的本地探索。你手上有一堆 CSV/Parquet，想快速跑聚合、做 pivot、连 Python 画图。
  • ETL 中间层。在管道里用 DuckDB 做数据清洗，不用把数据搬进专门的数仓。
  • 嵌入式分析。比如桌面应用、BI 工具内嵌，给用户提供 SQL 查询能力。
  • 学习 SQL 和测试小数据集。装个 pip 就完事。

我们团队现在把 DuckDB 作为所有 POC 工具。客户说“我有 500GB 数据，你试试”，我们第一反应不是搭集群，而是先让 DuckDB 跑压缩后的 150GB 子集，验证查询模型和结果正确性。这一招能节约至少 3 天时间。

不过这里有个陷阱：DuckDB 的内存管理虽然做了 spilling，但一旦工作集超过物理内存两倍，性能会断崖式下跌。我们测过 100GB 数据在 64GB 机器上强制 spilling，单查询从 4 秒变成 40 秒。所以如果你的数据量真的大于机器内存，别硬扛。

什么时候必须上 ClickHouse

另一个客户场景：金融风控，每天 8000 万条交易记录，需要保留 400 天，总量 320 亿行。查询需求是：“某用户过去 30 天内每小时的交易金额求和”，要求 P95 延迟 < 200ms，且并发 50 个分析师同时跑类似查询。

这个量级下 DuckDB 根本不可能。单机内存 256GB，但数据压缩后也有 600GB，没法常驻内存。DuckDB 每次查询都要读磁盘，冷查延迟 8 秒起步，并发 5 个就撞 CPU。更致命的是，DuckDB 不支持副本和故障转移——宕机一次就全没。

ClickHouse 用 8 节点集群（4 副本 × 2 分片）扛下来了。单查询延迟 180ms，50 并发下 P99 是 320ms。我们启用了轻量删除（Lightweight Delete）和 TTL，数据按天分区，旧分区在 400 天后自动离线。这套配置我们用了 3 周调优，主要是索引粒度（index_granularity）从默认 8192 调到 4096，以及主键顺序换成 (user_id, ts)。

推荐场景：

  • 实时监控与可观测性：日志、链路追踪、APM 指标。
  • 用户行为分析：数亿用户的留存漏斗、路径分析。
  • 广告与推荐系统：点击流多维聚合，要求低延迟。
  • 需要多租户隔离的 SaaS 分析产品。ClickHouse 的 RBAC 和查询队列比 DuckDB 成熟得多。

话说回来，ClickHouse 不是神。它最大的坑在 JOIN 和 UPDATE。分布式 JOIN 如果碰上数据分布不友好，性能直接崩。我们实测 5 亿行事实表 JOIN 3000 万行维表，如果维表不建全局字典，跑一组查询要 90 秒，而同样的数据在 DuckDB 单机只要 25 秒（因为单机全内存）。这提醒我们：ClickHouse 是为“宽表过滤聚合”设计的，不是为“雪花模型复杂关联”设计的。

评测维度的真正差异

除了上面对比表的硬件指标，有几个软维度在实际工程里更致命。

开发体验。 DuckDB 是纯 Python 包，pip install duckdb 完事，SQL 写完直接跑。ClickHouse 你得先装 server，再写建表 DDL，还要处理客户端。我们团队一个实习生用 DuckDB 花一个下午实现了数据抽样报告，而 ClickHouse 那边老员工配置权限就用了两天。但反过来说，DuckDB 没有查询日志、没有资源隔离、没有备份恢复工具 —— 这些坑在线上环境才暴露。

生态衔接。 DuckDB 跟 Pandas、Arrow 无缝互转，df.arrow() 两行代码。ClickHouse 有自己的 JDBC 驱动和 HTTP 接口，但要把结果转成 DataFrame 需要额外做序列化。我们测过 DuckDB 读 1.5GB Parquet 再输出 DataFrame 只要 0.8 秒，ClickHouse 从远程查询拿到同样数据要 2.1 秒。

成本模型。 DuckDB 零硬件部署成本，但你得自己管理服务器状态。ClickHouse 自带副本和负载均衡，却要 3 台以上机器起步。我们公司给 ClickHouse 集群买过 4 台 32 核机器，月成本 4800 元，DuckDB 跑在同一台开发机上零额外成本。

我个人认为，任何新项目在数据量低于 100GB 时，用 ClickHouse 都是浪费钱和时间。反过来，如果你预计一年内数据量会破 1TB，或者需要同时 20 个以上分析师并发查询，DuckDB 必定撑不住。这就像选语言：Python 脚本速度快，但它做不了 7×24 小时的高并发微服务。

选型决策树

下面这个流程我们在数次咨询后总结，虽然粗糙但有效：

  1. 先问数据量是否超过单机内存 3 倍？小于则直接考虑 DuckDB。
  2. 是否有 >10 并发查询？没有就用 DuckDB（单进程多线程能到 10 左右）。
  3. 是否需要高可用、故障转移？需要就 ClickHouse，不需要就走 DuckDB。
  4. 数据是否会有频繁的维度 JOIN？有则优先 DuckDB（除非你有耐心调全局字典）。
  5. 是否有多地域写入、跨集群复制？只有 ClickHouse 能原生支持。

拿我们的实际案子举例：日志分析平台，数据量 5TB，并发 80，必须 HA。决策树走下来，直接锁定 ClickHouse。相反，一个内部报表工具，数据 300GB，并发 3，维护团队只有 1 人——DuckDB + 定时刷新已经完全够用，上一套 ClickHouse 纯属自找苦吃。

不过决策树有个盲区：混合负载。有些团队既要做大规模实时聚合，又要临时跑复杂的、跨多张表的探索查询。这种场景选任何一方都别扭。我们团队的做法是双写：ClickHouse 处理高频监控查询，DuckDB 定期从 ClickHouse 导出子集做深度分析。代价是额外存储，但换来的灵活性值得。

局限与妥协

上面说了这么多，但我也得承认 DuckDB 不如 ClickHouse 的地方：DuckDB 没有真正的并发控制，一个连接内的事务冲突能锁死整个进程；没有分布式能力，单表 500GB 后你只能靠分文件硬切；网络访问也不友好，虽然 2024 年出了 DuckDB 扩展可以跑远程查询，但跟 ClickHouse 的分布式表、物化视图比还是幼儿园水平。

同样，ClickHouse 也有不如 DuckDB 的地方。它的单机查询复杂 JOIN 性能差，甚至不如 Postgres；内存表引擎容易内存爆炸；DML 写操作限制多（UPDATE/DELETE 是异步标记，读可能暂时不一致）；调试 SQL 时每次都要 system.query_log 里翻半天，远没有 DuckDB 的 PRAGMA 直观。

所以我的最终建议是：如果你的分析工作发生在本地、小数据、非生产环境，用 DuckDB，它帮你省掉一堆运维头发。如果你的分析工作要服务几十个用户、数据量持续增长、并且需要容错，咬牙上 ClickHouse，但要先接受它的 JOIN 短板和调优成本。

至于“能不能两个都用”？能，但要明确边界：DuckDB 负责研究型查询，ClickHouse 负责生产型查询。

第 2 周我们给客户交付时，架构图上两个引擎各占一端，中间用 Kafka 做数据流。老板看完说：“你们这到底是几个数据库？”我说：“一个负责赚钱，一个负责省钱。”

话说回来，DuckDB 在 2026 年会不会长出分布式能力？ ClickHouse 会不会优化单机 JOIN？谁知道呢。

别等未来，先理清你的查询模式，再选工具。