DuckDB 官方下场，把第三方协议打爆了

60M 行数据，Quack 只要 4.94 秒——同一个 DuckDB 引擎、同一批数据、同一台机器，Arrow Flight SQL 跑了 17.4 秒。

DuckDB 的定位一直很明确：单机、嵌入式、分析引擎。

但现实不会配合你的架构洁癖。AI Agent 要连上来查数据、BI 工具要接 ODBC、微服务之间要共享查询结果——你总不能让人家 import duckdb 然后在同一个进程里跑吧。

于是有了两个解法——

方案 A：第三方给 DuckDB 包一层网络协议，让它变成真正的 Server。这是 GizmoSQL 的路线。基于 Apache Arrow Flight SQL（gRPC 之上的标准化 SQL 协议），用 C++ 把 DuckDB 和 SQLite 包装成多租户 SQL 服务。

方案 B：DuckDB 团队自己下场。2026 年 5 月 12 日，他们发布了 Quack——一个内置于 DuckDB 的远程通信协议。不经过 Arrow、不经过 gRPC、不经过任何第三方库。数据从查询结果直接序列化到 HTTP 包。

然后他们跑了个对比测试。

● ● ●

一拳打穿：Quack 到底快多少

DuckDB 团队在 AWS m8g.2xlarge（8vCPU / 32GB RAM）上做了基准测试。两台机器同可用区，ping 延迟 0.28ms。

GizmoSQL 作为 Arrow Flight SQL 的代表参战。

批量传输（SQL 查询结果通过网络传输）：

小数据量时两者打平。但数据量越大，Quack 的优势越碾压——60M 行快了 3.5 倍。

小事务吞吐（8 线程并发 INSERT）：

Arrow Flight 在小事务上甚至不如 PostgreSQL。

● ● ●

为什么差这么多？解剖协议栈

Quack 和 Arrow Flight SQL 的分歧不在"网络快不快"，而在数据在谁手里、以什么形态传递。

Quack 的数据路径

DuckDB 查询引擎 → DuckDB 内部向量块 
    → 直接序列化为 application/duckdb MIME 类型 
    → HTTP/2 发送

零拐弯。DuckDB 查询出来的数据结构是什么样，发出去的字节就是什么样。序列化路径用的是 DuckDB 自身的 WAL 序列化——一条已经优化了多年的内部路径。

Arrow Flight SQL 的数据路径

DuckDB 查询引擎 → DuckDB 内部向量块 
    → Arrow C Data Interface 转换 → Apache Arrow 列式格式 
    → Arrow IPC 序列化 → gRPC/Protobuf 包装 
    → HTTP/2 发送

多了一层"格式通用化"的代价。Arrow Flight SQL 的目标是让不同数据库引擎都能说同一种语言——JDBC 的下一代替代品。通用性本身就是性能成本。

Ping 延迟也说明问题。 我在 WSL loopback 下实测：

1ms 的单次查询 overhead——对 AI Agent 的交互式查询来说完全可以接受。Arrow Flight SQL 至少要 2 次往返（GetFlightInfo + DoGet），overhead 在 5-10ms 级别。

● ● ●

但 Quack 不是全能的

快归快，Quack 有两个硬伤：

1. 客户端生态：DuckDB only

Quack 的客户端只有一个——另一个 DuckDB 实例。你不能用 JDBC 连、不能用 ODBC 连、不能用 Power BI 直连。

有个第三方的 quack-jdbc，但那是 GizmoData（对，就是 GizmoSQL 的作者 Philip Moore）写的。你猜他会不会优先维护竞争者协议的 JDBC 驱动？

GizmoSQL 这边：JDBC、ODBC、ADBC（Python/Go/C++）、SQLAlchemy、Ibis、CLI、JS/TS、Grafana 插件、Metabase 驱动、Power BI 连接器、QGIS 插件、dbt adapter、甚至 iOS App。一套全栈客户端矩阵，全是 Philip Moore 一个人写的。

2. 安全模型：挂反向代理代替

Quack 的安全是"最小化+可扩展"：启动时自动生成一个随机 token，要 TLS？挂 Nginx/Caddy。要细粒度权限？写 SQL Macro 做认证/授权回调。

GizmoSQL 的安全是"企业全栈"：TLS 1.2+、mTLS 双向认证、用户名+密码（SHA256）、JWT 自签名、外部 JWKS OIDC、Keycloak/Azure AD/Google SSO、目录级权限（glob 匹配）、Statement Queue 限流、KILL SESSION。

哪种更好？看你需要什么。如果需要对接企业 SSO 和审计系统，GizmoSQL 开箱即用。如果只需要两个 DuckDB 实例之间通信，Quack 的 token 就够了。

● ● ●

对比矩阵

根本分歧：通用性 vs 原生性。

Arrow Flight SQL（GizmoSQL）赌的是"一个协议连接万物"——不同数据库引擎、不同客户端语言、不同 BI 工具，都通过 Arrow 格式互操作。

Quack 赌的是"协议不该比引擎本身更复杂"——DuckDB 内部格式直接上 HTTP，源就是终点。

● ● ●

你会怎么选

如果你在做 AI Agent：选 Quack。 1ms overhead、零额外依赖、和 DuckDB 版本同步升级。Agent 不需要 JDBC。

如果你在做 BI 平台或需要多客户端接入：选 GizmoSQL。 别说 Quack 现在没有 JDBC——就算以后有了，GizmoSQL 的 Power BI / Grafana / Metabase 生态也不是一个 JDBC 驱动能补的。

如果你关心长期维护风险：赌 Quack。 DuckDB Labs 的 bus factor 远高于一个人。Philip Moore 是优秀的工程师，但如果他被 bus 撞了，GizmoSQL 就停更了。

两个方案不互斥。实际部署中，Nginx/Caddy 前端可以根据 URL path 路由到不同的后端。

● ● ●

最大变数

DuckDB 团队有没有可能在未来给 Quack 加上原生 JDBC/ODBC 支持？

如果他们做了——哪怕只做一个 JDBC 驱动——GizmoSQL 的大部分生态优势就会消失。Arrow Flight SQL 的性能劣势（3.5x）将成为硬伤。

但在那一天到来之前，GizmoSQL 仍然是连接 DuckDB 和"外部世界"最完整的桥梁。

复现代码： github.com/alitrack/labs/tree/master/duckdb/quack-bench

pip install duckdb>=1.5.3
python quack_bench_server.py   # 终端1
python quack_bench_client.py   # 终端2

测试环境：Quack 实测数据使用 DuckDB 1.5.3 + Python，WSL loopback 模式。基准对比数据来自 DuckDB 官方博客。