DuckDB 单节点瓶颈迫使用户迁移
推荐指数 57.0 NO. 020 · 2026.11.03
发布2026/11/02Score156Comments106
简介
一家数据公司将数仓从 DuckDB 迁回 ClickHouse，因客户工作负载增长超出单节点承载能力。对正在评估嵌入式分析方案的工程师有直接参考意义：DuckDB 适合单机场景，但多租户 SaaS 数仓需要分布式架构。
编辑判断
DuckDB 的 Postgres 协议兼容和 dbt 生态接入让它成为快速启动分析项目的首选，但这次迁移暴露了嵌入式数据库的结构性天花板：当客户查询从分钟级走向小时级且并发增长时，缺乏分布式执行和全局优化器会成为致命伤。
ClickHouse 近期在查询优化器上的投入（如 Analyzer 架构）正在缩小与 Snowflake/BigQuery 的体验差距，而 DuckDB 的 MotherDuck 托管服务也在尝试突破单节点限制。如果你正在基于 DuckDB 构建多租户产品，建议提前设计好「单机→分布式」的逃生通道，而不是像这家公司一样被迫三个月重写。
社区反馈
负面 99 条评论
核心争论：DuckDB单节点瓶颈是否被合理评估，还是工程团队缺乏测量就盲目迁移
Is Quack, the DuckDB client-server protocol, something that could have helped them with the scaling problems they encountered?
Author here. Good question. AFAIK you cannot use Quack for anything that looks remotely like distributed querying.
Am I missing something here, or is the only technical detail in the post "a trillion rows is a lot of data, maybe trying trinio will work this time"? It feels like a lot of churn and not a lot of measurements or engineering.