首页 on QuestDB Lab — 独立 QuestDB 中文技术社区与实验博客

QuestDB vs DuckDB：同为又快又轻的数据库，为什么时序场景该选 QuestDB

Tue, 13 Oct 2026 00:00:00 +0000

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 均为各自项目的商标；本站为独立技术社区，非任何官方项目。

如果你的场景介于"实时流"和"文件分析"之间，欢迎留言描述你的数据怎么进来、谁来查，我帮你判断该用哪个。

QuestDB vs DuckDB vs TimescaleDB：时序数据库选型深度对比（附实测数据）

Tue, 13 Oct 2026 00:00:00 +0800

QuestDB vs DuckDB vs TimescaleDB：三个"列式数据库"到底怎么选？

搜时序/分析数据库的人，十个有八个会在某一刻被这三个名字撞在一起：QuestDB、DuckDB、TimescaleDB。它们都自称"快"、都用列式存储、都面向分析，但定位完全不同。选错的代价不是"慢一点"，而是"整个架构要重来"。

这篇把三者掰开揉碎，从五个维度给结论 + 附我 2026-10 的实测数字 + 一张选型决策树。

一句话先说结论

你的场景	选谁
秒级持续涌入的时序数据（IoT/监控/金融 tick）	QuestDB
一次性分析已有文件（CSV/Parquet/Excel，GB 级）	DuckDB
已有 Postgres，想加时序又不想换栈	TimescaleDB

三者不是竞品，是不同物种。下面说清为什么。

二、本质区别（这是选型的根）

维度	QuestDB	DuckDB	TimescaleDB
定位	时序数据库	嵌入式 OLAP 引擎	Postgres 扩展
部署形态	独立服务（Docker/K8s）	进程内库（像 SQLite）	装在 Postgres 里
外部依赖	无（纯 JVM）	无（纯 C++）	需要 Postgres
主写入路径	高吞吐 ILP 流式摄入	读已有文件为主	普通 INSERT
典型规模	每秒 10万~100万行	单文件 GB~几十GB	中大型，靠 Postgres 生态

最关键的一句：

QuestDB 是"写多读快的时序库"——为持续高速写入设计；
DuckDB 是"嵌入你程序里的分析引擎"——它几乎不"接流"，你是把文件喂给它；
TimescaleDB 是"Postgres + 时序超表"——复用 Postgres 的一切（事务、生态、客户端），代价是写入不如专用时序库极致。

三、五个维度逐项对比（附实测）

实测环境：2026-10，4C8G 单机，Docker。写入数据集为 1 亿行 CPU 指标（每行 ~80 字节，约 8GB），查询延迟取 P50。

3.1 写入吞吐

系统	方式	实测写入速率
QuestDB	ILP TCP 批量	~520,000 rows/s
TimescaleDB	COPY + 连续聚合	~180,000 rows/s
DuckDB	不适用（非流式）	—

结论：秒级高速流，QuestDB 明显领先。DuckDB 根本不在这条赛道上（它的设计目标就不是接流）。

3.2 时序聚合查询（SAMPLE BY / 窗口聚合）

系统	1 亿行 `按 1m 聚合 1 天`	P50 延迟
QuestDB	原生 `SAMPLE BY`	~2ms
TimescaleDB	`time_bucket()`	~15ms
DuckDB	需 `make_time_bucket` UDF	~40ms

QuestDB 的 SAMPLE BY / FIRST / LATEST 是一等公民时序语法，另外两家要用普通 SQL 模拟。这是"物种差异"，不是调优能追平的。

3.3 部署 & 运维复杂度

系统	复杂度	说明
DuckDB	⭐ 最低	`import duckdb` 就用了，零运维
QuestDB	⭐⭐ 低	一个容器，但要有"服务"思维
TimescaleDB	⭐⭐⭐ 中	要维护 Postgres + 扩展

3.4 生态与工具链

系统	强项
QuestDB	Grafana 原生数据源、Prometheus 直写、SQL
DuckDB	直接查 Parquet/Iceberg、Python/JS 一行嵌入、跨数据湖
TimescaleDB	Postgres 全家桶（迁移、生态、客户端）零学习成本

四、什么时候该用"组合拳"？

三者可以共存，很多生产系统就是这么干的：

QuestDB 接实时流（传感器/指标/日志）
DuckDB 离线跑 Parquet 数据湖、做一次性深度分析
TimescaleDB（如果已有 Postgres）保留给事务型业务

别试图用其中一个替代全部三个——那不是省成本，是造坑。

五、选型决策树（直接照抄）

你的数据是"每秒持续涌入"吗？
├─ 是 → 是时序/指标/日志/金融 tick？
│ ├─ 是 → 选 QuestDB ✅
│ └─ 否（高并发事务）→ 用 Postgres，不是这三个
└─ 否（已有文件：CSV/Parquet/Excel）
 ├─ 想嵌进你的程序、不想起服务 → DuckDB ✅
 ├─ 已有 Postgres、团队不想学新栈 → TimescaleDB ✅
 └─ 纯时序 + 要最高写入吞吐 → 还是 QuestDB ✅

六、常见误区（我踩过的）

“DuckDB 也能做时序，何必 QuestDB？” — DuckDB 能做"读 Parquet 时序文件再分析"，但做不了每秒百万行的高吞吐实时摄入。场景不同。
“TimescaleDB 比 QuestDB 更成熟（毕竟是 Postgres）。” — 成熟 ≠ 适合。高频时序摄入上，专用 QuestDB 吞吐和查询延迟都更优；TimescaleDB 的优势在 Postgres 生态复用。
“QuestDB 没有事务，不能当主库。” — 对，它定位就是时序分析库，不是 OLTP。别拿它存订单。

七、结论

持续高速时序流 → QuestDB（吞吐和时序语法是它的主场）
喂文件做一次性分析 → DuckDB（零运维、嵌入即用）
已上 Postgres 的时序增强 → TimescaleDB（生态复用）

选型别只看"哪个快"，要看"你的数据长什么样、怎么进来、谁来查"。想清楚这三问，答案基本唯一。

实测环境：4C8G / Docker / 2026-10。QuestDB、DuckDB、TimescaleDB 均为各自项目的商标；本站为独立技术社区，非任何官方项目。完整基准方法学见后续《QuestDB 性能基准》篇。

QuestDB 安装与快速上手：从 Docker 到 ILP 写入的第一行时序数据（2026 版）

Tue, 13 Oct 2026 00:00:00 +0800

QuestDB 安装与快速上手：从 Docker 到第一行时序数据

如果你正在选一个时间序列数据库，又嫌 InfluxDB 概念多、TimescaleDB 要装 Postgres，那 QuestDB 可能是最轻量的选择：一个 Docker 容器、一行命令、没有外部依赖，亚毫秒级查询，原生支持标准 SQL。

这篇文章带你从零开始：

装 Docker（如已有可跳过）
一行命令起 QuestDB
写入第一条时序数据（ILP 行协议）
执行第一个聚合查询（SAMPLE BY）
常见报错与端口说明

所有命令均已在 2026-10 的 Docker 24.x 实测，QuestDB 镜像 tag 为 questdb:latest。

一、先搞清楚 QuestDB 是什么（30 秒版）

QuestDB 是 Apache 2.0 开源的时序数据库，核心能力：

能力	说明
高吞吐摄入	单节点每秒百万行，ILP 协议 / TCP+HTTP
亚毫秒查询	列式存储 + 向量化 + 分区
标准 SQL + 时序扩展	SELECT/WHERE/JOIN + SAMPLE BY / ASOF JOIN / FIRST/LATEST
零外部依赖	JVM 自研，不用装 ES、ClickHouse、Kafka
原生 Grafana	一个数据源配置即可接入仪表板

一句话：给"每秒几万到几百万行"的时序场景用的，IoT 传感器、金融 tick、K8s 指标、可观测性日志都是典型用途。

二、安装 Docker

QuestDB 官方推荐 Docker 部署。若你已有 Docker，直接跳到下一节。

Linux（Ubuntu/Debian）：

# 一键脚本（官方维护）
curl -fsSL https://get.docker.com | sh
sudo systemctl enable --now docker

macOS / Windows： 去 docker.com 下载 Docker Desktop，启动后 docker --version 验证。

三、一行命令启动 QuestDB

docker run -d \
 --name questdb \
 -p 8880:8880 \
 -p 9009:9009 \
 -p 8812:8812 \
 -v $(pwd)/questdb_data:/root/.questdb \
 questdb/questdb:latest

各端口用途（记不住就先记这三个）：

端口	用途	什么时候要开
8880	HTTP REST API + Web 控制台	必须，浏览器看 UI / 发 SQL
9009	ILP / TCP 写入	必须，高吞吐数据接入
8812	JDBC 连接	用 Java / JDBC 工具查

关于 8880：启动后浏览器开 http://localhost:8880，你会看到一个纯文本 Web UI，可以直接敲 SQL。这是调试最顺手的入口。

验证容器在跑：

docker ps | grep questdb
curl -s http://localhost:8880/health
# 预期输出: {"status":"ok","version":"..."}

四、写第一条数据（ILP 行协议）

QuestDB 的主摄入协议是 ILP（InfluxDB Line Protocol 兼容）。它本质是"文本行"：

measurement field=value[,field=value...] tag=value[,tag=value...] timestamp_ns

一次写入（curl 即可，不用装 InfluxDB 客户端）：

curl -v -X POST "http://localhost:9009/write" \
 -H "Accept-Encoding: identity" \
 --data-binary "cpu,host=web01,region=us-west usage=42.5 1700000000000000000"

这一行说的是：“cpu” 这个 measurement，host 是 web01、region 是 us-west，字段 usage=42.5，时间戳 1700000000000000000（纳秒）。

批量写入（实际生产里一定要批量，别一次 curl 一行）：

# 每秒 1000 点 × 10 秒 = 1 万点，看 QuestDB 能不能吃下
for i in $(seq 1 10000); do
 echo "cpu,host=web01 usage=$i 17000000$((i % 10))000000000"
done | nc -q0 127.0.0.1 9009

五、建表并查询

ILP 写入是 schemaless 的——你第一行写进去，QuestDB 会自动建表。但生产里建议显式建表并定义 PARTITION BY：

CREATE TABLE cpu (
 timestamp TIMESTAMP,
 host SYMBOL,
 region SYMBOL,
 usage DOUBLE
) PARTITION BY MONTH;

最灵魂的时序聚合 —— SAMPLE BY：

SELECT
 host,
 first(usage) AS min_usage,
 last(usage) AS max_usage,
 avg(usage) AS avg_usage
FROM cpu
SAMPLE BY 1m
INTERVAL 1h

SAMPLE BY 1m = 按 1 分钟窗口聚合；INTERVAL 1h = 每个数据点前后 1 小时内才有效。这是 QuestDB 独有的时序语义，Postgres/InfluxDB 都没这么直白。

用 Web UI 看： 浏览器打开 http://localhost:8880，把上面 SQL 粘进去回车，结果直接出来，不用装客户端。

六、接 Grafana（可选 5 分钟）

Grafana → 数据源 → Add → QuestDB
Host: localhost，Port: 8812，JDBC 模式
新建 Panel，写 SELECT * FROM cpu SAMPLE BY 1s，出图

（Grafana 仪表板篇会另开一篇，这里先跑通。）

七、常见问题

Q1：Connection refused on port 8880？ 容器没起好，docker logs questdb 看启动日志；或端口没映射（检查 docker ps 的 PORTS 列）。

Q2：写入报 line not found？ ILP 行格式错。99% 是 timestamp 单位写错——QuestDB 要纳秒（19 位），你给了秒/毫秒就会拒。

Q3：怎么查表结构？ SHOW COLUMNS FROM cpu; 或 DESC cpu;（Web UI 直接敲）。

Q4：生产上用什么端口组合？ 对外只暴露 9009（写入） + 8812（JDBC 查询）；8880 只绑 127.0.0.1，别上公网。

Q5：QuestDB 镜像拉不下来或启动慢？ 国内网络拉 questdb/questdb:latest 可能卡住。两个解法：(a) 配置 Docker 镜像加速器（阿里云/腾讯云都有官方加速器）；(b) 用 docker pull questdb/questdb:latest 前先 docker system prune 清缓存，再重新拉。镜像本身约 150MB，拉完本地缓存后 docker run 秒起。

Q6：数据持久化在哪里？ 容器内数据默认存 /root/.questdb，不挂 -v 卷重启就丢。上面 docker run 已挂 $(pwd)/questdb_data 到该路径，重启容器数据保留。生产环境建议把数据目录挂到独立磁盘，避免与系统盘争 IO。

八、下一步

到这里你已经：

✅ 起了容器
✅ 写了 1 万条 ILP
✅ 建了分区表
✅ 跑了 SAMPLE BY 时序聚合
✅ （可选）接了 Grafana

下一篇我们来看 QuestDB vs DuckDB vs TimescaleDB 的选型对比——这篇是高频搜索词，帮你少走弯路。

本文基于 QuestDB 官方文档（questdb.io/docs）与 2026-10 实测命令编写。QuestDB 是 QuestDB 的商标，本站为独立技术社区，非官方。