DuckDB Quack 协议：原生客户端-服务端架构全面解析

Fri, 15 May 2026 00:00:00 +0000

引言

DuckDB 自诞生以来一直以"嵌入式分析数据库"著称——它像 SQLite 一样嵌入到宿主进程中，无需单独部署服务端。这个设计带来的优势显而易见：零运维、零配置、毫秒级启动。但它也带来一个无法回避的硬伤：无法多进程并发访问同一个数据库文件。

如果你的场景是：

10 个采集器同时向同一个数据库写入埋点日志
一个 Dashboard 在实时查询，同时后台在跑批量 ETL
多个微服务需要共享同一个分析数据源

那么抱歉，DuckDB 原生不支持。多个进程同时写同一个 .db 文件，轻则数据损坏，重则进程崩溃。

以前你怎么解决这个问题？

用 pg_duckdb —— 给 PostgreSQL 套一层 DuckDB 的执行引擎，曲线救国
用 MotherDuck —— 数据上云，花钱买 SaaS
换 PostgreSQL/ClickHouse —— 为了一个并发功能换掉整个技术栈
自己写代理层 —— 用 Redis 或消息队列做写缓冲，自行处理冲突

这些方案要么贵、要么复杂、要么引入了额外的运维负担。

2026 年 5 月，DuckDB 团队交出了一份全新的答卷——Quack 协议。一个构建在 HTTP 之上的原生远程通信协议，让 DuckDB 实例之间可以像 PostgreSQL 的客户端-服务端那样通信。这不是一个第三方插件，而是 DuckDB 核心团队开发的官方扩展。

Quack 协议的核心架构

设计理念

Quack 的设计哲学可以概括为三个关键词：

原生集成 — 不是外部代理，而是 DuckDB 扩展，INSTALL quack 一行命令即可启用
单次往返 — 一次查询只需 1 次 network round trip，远比 Arrow Flight SQL（至少 2 次）高效
HTTP 之上 — 基于 HTTP 协议构建，兼容现有网络基础设施，无需特殊端口或协议支持

架构图

┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ DuckDB │ │ DuckDB │ │ DuckDB │
│ 客户端 A │ │ 客户端 B │ │ 客户端 C │
│ (采集器1) │ │ (采集器2) │ │ (Dashboard) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
 │ │ │
 └───────────────────┼───────────────────┘
 │ HTTP
 ▼
 ┌─────────────┐
 │ DuckDB │
 │ 服务端 │
 │ (数据存储) │
 └─────────────┘
 │
 ▼
 ┌─────────────┐
 │ .db 文件 │
 │ (单写者锁) │
 └─────────────┘

注意：Quack 服务端本身是单进程访问 .db 文件的，但它可以接收来自多个客户端的请求，在服务端内部进行串行化处理。这样就实现了"外部并发、内部串行"的架构，既保证了数据一致性，又提供了并发访问的能力。

快速上手

服务端启动

-- 在服务器上启动 DuckDB，执行以下命令
INSTALL quack FROM core_nightly;
LOAD quack;

-- 启动 Quack 服务监听 localhost:8338
-- token 用于客户端认证
CALL quack_serve('quack:localhost', token = 'super_secret');

-- 创建一些测试数据
CREATE TABLE events AS
SELECT * FROM read_csv_auto('events.csv');

客户端连接

-- 在客户端机器上执行
INSTALL quack FROM core_nightly;
LOAD quack;

-- 创建认证密钥
CREATE SECRET (
 TYPE quack,
 TOKEN 'super_secret'
);

-- 挂载远程数据库
ATTACH 'quack:localhost' AS remote_db;

-- 查询远程表
SELECT count(*), event_type
FROM remote_db.events
GROUP BY event_type;

-- 写数据到远程
INSERT INTO remote_db.events
SELECT * FROM read_csv_auto('new_events.csv');

一次往返的秘密

Quack 将查询的元数据（schema、统计信息）打包到查询结果中一起返回。传统协议（如 Arrow Flight SQL）需要先请求元数据、再请求数据，至少 2 次往返。Quack 在 TCP 层面做了精细调优，将查询计划序列化后嵌入 HTTP 请求体，服务端执行后直接返回完整结果。

这意味着在延迟较高的网络环境（如跨区域部署）中，Quack 的优势会被放大。

性能基准测试

DuckDB 团队在 AWS Arm 架构上进行了严格的基准测试，以下是核心数据：

批量传输性能

测试条件：60,000,000 行数据，约 76GB CSV 文件

协议	耗时	相对性能
Quack	< 5 秒	基线
Arrow Flight SQL	略慢于 Quack	~90-95%
PostgreSQL (COPY)	慢数个数量级	<1%

小事务并发性能

测试条件：单行 INSERT，持续 5 秒

协议	峰值 TPS	备注
Quack	~5,500	8 线程并发
Arrow Flight SQL	~2,500	约为 Quack 的一半
PostgreSQL	更高 (10,000+)	但架构完全不同

理解这些数字

5,500 TPS 意味着每秒钟可以处理 5,500 个独立的 INSERT 事务。对于日志采集场景，如果你每秒产生 5,000 条日志，一个 Quack 服务端足够应对。
< 5 秒传输 60M 行 意味着你可以用 Quack 做大规模数据同步，而非仅限于 OLTP 式的小事务。

Quack vs. 传统方案对比

维度	Quack	PostgreSQL	MotherDuck	自建代理层
部署复杂度	🔥 极低（一行命令）	⚠️ 中等（配置主从）	❌ 高（数据上云）	❌ 高（开发+运维）
运维成本	✅ 几乎为零	⚠️ 需要 DBA	❌ 按量付费	❌ 自行维护
查询延迟	🔥 1 次往返	✅ 2-3 次往返	⚠️ 网络延迟高	⚠️ 取决于代理实现
小事务 TPS	~5,500	10,000+	受限于网络	取决于缓冲策略
批量传输 (60M行)	< 5 秒	极慢	受限于带宽	受限于带宽
数据本地性	✅ 数据在本地	✅ 数据在本地	❌ 数据在云端	✅ 数据在本地
费用	💰 完全免费	💰 免费（自建）	💸 $20+/月起步	💰 开发成本
与 DuckDB API 兼容性	🔥 100% 兼容	⚠️ 需适配 pg	✅ 兼容	✅ 兼容

实际落地场景

场景 1：多采集器日志汇聚

需求： 10 台服务器上的采集程序需要将访问日志写入同一个数据库，同时数据分析师需要实时查询。

架构：

# 服务端（一台 4C8G 服务器）
duckdb -c "
INSTALL quack FROM core_nightly;
LOAD quack;
CALL quack_serve('quack:0.0.0.0', token = 'my-token');
"

# 每台采集器上
while true; do
 duckdb -c "
 INSTALL quack FROM core_nightly;
 LOAD quack;
 CREATE SECRET (TYPE quack, TOKEN 'my-token');
 ATTACH 'quack:server-ip:8338' AS remote;
 INSERT INTO remote.access_logs
 SELECT * FROM read_csv_auto('/var/log/access/$(date +%H).csv');
 "
 sleep 60
done

场景 2：轻量级 OLAP 服务

需求： 给 20 个内部用户提供一个 SQL 查询接口，每个人都能查全量数据，但不能互相干扰。

-- 服务端预加载数据
ATTACH './warehouse.db' AS warehouse;

-- 客户端只需挂载
duckdb -c "
INSTALL quack FROM core_nightly;
LOAD quack;
CREATE SECRET (TYPE quack, TOKEN 'analytics-token');
ATTACH 'quack:analytics.internal:8338' AS warehouse;
-- 现在可以像本地表一样查询
SELECT department, sum(revenue)
FROM warehouse.sales
WHERE sale_date >= '2026-01-01'
GROUP BY department
ORDER BY sum(revenue) DESC;
"

场景 3：替代 ELK 的轻量日志方案

架构对比：

方案	组件	资源消耗	运维复杂度
ELK Stack	Elasticsearch + Logstash + Kibana + Filebeat	16GB+ RAM	高
DuckDB + Quack	DuckDB + 采集脚本	< 2GB RAM	极低

对中小企业来说，ELK 太重了。用 Quack + DuckDB，一台 4C8G 的服务器可以轻松处理每天数亿条日志的写入和查询。

局限性

任何技术都有短板，Quack 也不例外：

单写者限制 — Quack 服务端内部仍然是单线程写入 .db 文件的，写入性能上限受限于 DuckDB 的写入能力。如果你的场景需要 50,000+ TPS，请考虑其他方案。
安全模型简单 — 目前仅支持 Token 认证，没有用户权限管理、SSL/TLS 需要自行在前面加反向代理。
网络敏感性 — 虽然 1 次往返很优秀，但如果客户端和服务端之间的延迟超过 100ms，查询体验仍会受影响。
仍在 nightly 阶段 — Quack 目前从 core_nightly 仓库安装，尚未进入正式发布渠道。建议在测试环境充分验证后再上生产。

变现建议

轻量级日志分析 SaaS — 用 Quack 做后端，提供给中小企业替代 ELK，$29/月起，一台服务器可以服务 50-100 个客户
数据分析咨询 — 帮客户从 PostgreSQL/MySQL 迁移到 DuckDB + Quack 架构，每个项目报价 ¥5,000-¥20,000
多租户报表平台 — 每个租户一个 DuckDB 实例，通过 Quack 提供查询服务，月付 ¥299-¥999
培训与教程 — 围绕 Quack 的部署、调优、灾备方案制作付费教程，定价 ¥99-¥299

总结

Quack 不只是一个新协议，它是 DuckDB 从"单机分析工具"走向"生产级数据处理引擎"的关键一步。它解决了 DuckDB 长期以来最大的痛点——多进程并发访问，同时保持了 DuckDB 一贯的"零配置、高性能"基因。

对于正在使用或考虑使用 DuckDB 的团队，Quack 值得你现在就开始关注和测试。当它进入稳定版时，你的架构方案已经准备好了。

参考链接

DuckDB Quack 扩展文档: https://duckdb.org/docs/current/extensions/quack
DuckDB 官方博客: https://duckdb.org/news/
GitHub Discussion: https://github.com/duckdb/duckdb/discussions

生产部署 on DuckDB 实验室