引言

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

如果你的场景是：

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

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

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

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

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

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

Quack 协议的核心架构

设计理念

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

1. 原生集成 — 不是外部代理，而是 DuckDB 扩展，INSTALL quack 一行命令即可启用
2. 单次往返 — 一次查询只需 1 次 network round trip，远比 Arrow Flight SQL（至少 2 次）高效
3. 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 文件

小事务并发性能

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

理解这些数字

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

Quack vs. 传统方案对比

实际落地场景

场景 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 太重了。用 Quack + DuckDB，一台 4C8G 的服务器可以轻松处理每天数亿条日志的写入和查询。

局限性

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

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

变现建议

1. 轻量级日志分析 SaaS — 用 Quack 做后端，提供给中小企业替代 ELK，$29/月起，一台服务器可以服务 50-100 个客户
2. 数据分析咨询 — 帮客户从 PostgreSQL/MySQL 迁移到 DuckDB + Quack 架构，每个项目报价 ¥5,000-¥20,000
3. 多租户报表平台 — 每个租户一个 DuckDB 实例，通过 Quack 提供查询服务，月付 ¥299-¥999
4. 培训与教程 — 围绕 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