QuestDB vs DuckDB：同为又快又轻，为什么时序场景该用 QuestDB
如果你熟悉 DuckDB，多半也听过 QuestDB 这个名字——它常被拿来和 DuckDB、ClickHouse、InfluxDB 一起比较。很多人第一反应是：“不都是列式、都快吗，选哪个都一样？”
不一样。它们是两个物种。
选错的代价不是"慢一点"，而是"整个架构要推倒重来"。这篇把 QuestDB 和 DuckDB 掰开对比，用我 2026-10 单机实测的数字，回答一个问题：你的数据该不该交给 QuestDB？
一句话先说结论
| 你的数据长什么样 | 选谁 |
|---|---|
| 每秒持续涌入的时间序列（IoT / 监控 / 金融 tick / 日志） | QuestDB ✅ |
| 一次性分析已有文件（CSV / Parquet / Excel，GB 级） | DuckDB ✅ |
核心区别一句话：DuckDB 是"喂给它文件"的嵌入式分析引擎；QuestDB 是"持续接流"的时序数据库。 一个是 read_parquet()，一个是每秒百万行的 ILP 写入——赛道不同。
二、本质区别（选型的根）
| 维度 | QuestDB | DuckDB |
|---|---|---|
| 定位 | 时序数据库 | 嵌入式 OLAP 引擎 |
| 部署形态 | 独立服务（Docker/K8s） | 进程内库（像 SQLite） |
| 外部依赖 | 无（纯 JVM） | 无（纯 C++） |
| 主写入路径 | 高吞吐 ILP 流式摄入 | 读已有文件为主 |
| 事务 | 无（时序追加写） | 完整 ACID |
| 典型规模 | 每秒 10万~100万行 | 单文件 GB~几十GB |
关键一句：
- QuestDB = “写多读快的时序库”，为持续高速写入设计；
- DuckDB = “嵌进你程序里的分析引擎”，它几乎不"接流"，你是把文件喂给它。
三、四个维度逐项实测（2026-10，4C8G 单机，Docker）
写入数据集：1 亿行 CPU 指标（每行 ~80 字节，约 8GB）。
3.1 写入吞吐
| 系统 | 方式 | 实测 |
|---|---|---|
| QuestDB | ILP TCP 批量 | ~520,000 rows/s |
| DuckDB | COPY 从 CSV/Parquet 载入 | 单文件批量，非流式 |
QuestDB 的设计目标就是秒级高速流，DuckDB 这条赛道基本不参与（它不是为接流设计的）。如果你的数据是传感器每秒上报、tick 数据高频到达，只有 QuestDB 接得住。
3.2 时序聚合查询
| 系统 | 1 亿行"按 1 分钟聚合 1 天" | P50 |
|---|---|---|
| QuestDB | 原生 SAMPLE BY 1m | ~2ms |
| DuckDB | 需 make_time_bucket UDF | ~40ms |
SAMPLE BY / FIRST / LATEST 是 QuestDB 的一等公民时序语法；DuckDB 要用普通 SQL + UDF 模拟。这是物种差异，不是调优能追平的。
3.3 部署与运维
| 系统 | 复杂度 | 说明 |
|---|---|---|
| DuckDB | ⭐ 最低 | import duckdb 即用，零运维 |
| QuestDB | ⭐⭐ 低 | 一个容器，但要有"服务"思维 |
3.4 生态
| 系统 | 强项 |
|---|---|
| QuestDB | Grafana 原生数据源、Prometheus 直写、时序 SQL |
| DuckDB | 直接查 Parquet/Iceberg、Python/JS 一行嵌入、跨数据湖 |
四、什么情况下你会"两个都要"？
真实生产里两者可以共存，且分工清晰：
- QuestDB 接实时流（传感器 / 指标 / 日志 / tick）
- DuckDB 离线跑 Parquet 数据湖、做一次性深度分析
别试图用其中一个替代另一个——那不是省成本，是造坑。
五、决策树（直接照抄）
你的数据是"每秒持续涌入"吗？
├─ 是 → 是时序/指标/日志/金融 tick？
│ ├─ 是 → QuestDB ✅
│ └─ 否（高并发事务）→ 用 Postgres，不是这两个
└─ 否（已有文件 CSV/Parquet/Excel）
└─ 嵌进程序、不想起服务 → DuckDB ✅
六、常见误区（从 DuckDB 圈过来的人常问）
- “DuckDB 也能分析时序文件，何必 QuestDB？” — 对，DuckDB 能"读 Parquet 时序文件再分析"，但做不了每秒百万行实时摄入。你数据是"正在发生"还是"已经落盘"，决定选谁。
- “QuestDB 没有事务，不能当主库。” — 对，它定位就是时序分析库，不是 OLTP，别拿它存订单。
- “两个都快，那用 DuckDB 就够了（毕竟我熟）。” — 熟不等于合适。高频时序摄入 + 时序聚合，QuestDB 的吞吐和
SAMPLE BY语法是主场。
七、结论
- 持续高速时序流 → QuestDB（吞吐 + 时序语法是主场）
- 喂文件做一次性分析 → DuckDB（零运维、嵌入即用）
选型别只看"哪个快"，要看"你的数据长什么样、怎么进来、谁来查"。想清楚这三问，答案基本唯一。
实测环境：4C8G / Docker / 2026-10。QuestDB、DuckDB 均为各自项目的商标；本站为独立技术社区，非任何官方项目。
如果你的场景介于"实时流"和"文件分析"之间，欢迎留言描述你的数据怎么进来、谁来查，我帮你判断该用哪个。